[CRIU] Towards an in-process libcriu

Pavel Emelyanov xemul at parallels.com
Mon Aug 4 07:53:13 PDT 2014


On 08/04/2014 06:51 PM, Serge Hallyn wrote:
> Quoting Pavel Emelyanov (xemul at parallels.com):
>> On 07/17/2014 06:40 PM, Serge Hallyn wrote:
>>> Quoting Pavel Emelyanov (xemul at parallels.com):
>>>> On 07/17/2014 12:41 AM, Saied Kazemi wrote:
>>>>> Having libcriu with C bindings is a great feature.  In addition to LXC as Tycho has mentioned,
>>>>> other Docker exec drivers will be able to use it too.  In fact, from within any program, one 
>>>>> would call dump() and restore() to do what is currently done on the command line.
>>>>
>>>> But you can call dump and restore from libcriu right now. The only requirement is
>>>> to have criu service launched. What problems do you have with that?
>>>>
>>>> As I mentioned the biggest concern is -- the in-code libcriu would be root-only.
>>>> Would this work with Docker, as AFAIR it starts from non-root user?
>>>
>>> This *would* be a disappointment for lxc since we can now create and start
>>> containers without being root;  but I rather assumed it was the case for
>>> criu anyway.  If you are saying that, if we write a simple c library, we
>>> can dump non-root tasks without being root (as we used to with the old
>>> cryo ptrace-based one :)  that would rock and could justify the effort.
>>
>> We can do that, but this would require patching the kernel. For example,
>> criu heavily uses the /proc/pid/map_files/ directory which is CAP_SYS_ADMIN
>> only. And there are quite a few more places in the kernel with the same.
> 
> Some of that should definately be eligble for relaxation.

Here's how we are trying to relax the prctl's restrictions:
 https://lkml.org/lkml/2014/7/3/532

:)

Thanks,
Pavel




More information about the CRIU mailing list