[CRIU] Towards an in-process libcriu

[Serge Hallyn]

Quoting Pavel Emelyanov (xemul at parallels.com):
> 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
> 
> :)

Yeah, the latest version of that is still in my inbox.  Will review.