[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