[CRIU] Re: [PATCH 0/5] IPC: checkpoint/restore in userspace enhancements

Casey Schaufler casey at schaufler-ca.com
Mon Feb 13 12:39:53 EST 2012


On 2/13/2012 8:48 AM, Stanislav Kinsbursky wrote:
> 13.02.2012 20:11, Serge Hallyn пишет:
>> Quoting Stanislav Kinsbursky (skinsbursky at parallels.com):
>>> 10.02.2012 22:29, Casey Schaufler пишет:
>>>> On 2/9/2012 10:01 AM, Stanislav Kinsbursky wrote:
>>>>> This patch set aimed to provide additional functionality for all 
>>>>> IPC objects,
>>>>> which is required for migration these objects by user-space 
>>>>> checkpoint/restore
>>>>> utils.
>>>>> The main problem here was impossibility to set up object id. This 
>>>>> patch set
>>>>> solves the problem in two steps:
>>>>> 1) Makes it possible to create new object (shared memory, 
>>>>> semaphores set or
>>>>> messages queue) with ID, equal to passed key.
>>>>> 2) Makes it possible to change existent object key.
>>>>
>>>> Is there any chance you might include the LSM data as well?
>>>>
>>>
>>> Sorry, but I don't understand your question.
>>> What is this "LSM"? Linux Shared Memory? If yes, and you mean SYSV
>>> IPC SHM, then where do you want to include it?
>>
>> He means linux security modules.  (see include/linux/security.h)
>
> Ok, thanks for explanation.
> Casey, what exactly you are asking about? Am I going to implement 
> security_*_set() functions?
>

The IPC objects are queer beasts in that they are both
volatile and persistent. If you restart a process that
uses IPC objects they may have to be recreated, which is
what your code is doing. If the system is using an LSM
there may be information attached to the IPC object that
can not be derived from the process being restarted.

That's a roundabout way of saying yes, you may need to
implement security_sem_set and friends
security_{sem,shm,msg}_[ge]et(). The good news is that
I know of at least one other project that is looking
to implement those functions for unrelated reasons.




More information about the CRIU mailing list