[CRIU] Towards an in-process libcriu

[Tycho Andersen]

Hi Pavel,

On Thu, Jul 17, 2014 at 01:34:23PM +0400, Pavel Emelyanov wrote:
> On 07/16/2014 10:41 PM, Tycho Andersen wrote:
> > Hi Ruslan,
> > 
> > On Wed, Jul 16, 2014 at 09:10:36PM +0300, Ruslan Kuprieiev wrote:
> >> Hi Tycho,
> >>
> >> could you describe what do you want to do and why libcriu and RPC
> >> don't match
> >> your needs?
> > 
> > I'm working on integrating criu directly into lxc, so there can be
> > commands like lxc-checkpoint and lxc-restore. If I understand things
> > correctly, we'll either have to run a criu daemon all the time, or
> > spawn one when they run lxc-{checkpoint,restore}, do the checkpoint or
> > restore, and then kill it off. It seems much cleaner to me just to
> > have a set of library functions that we could do this with in process.
> 
> Yes, this is doable and useful.
> 
> > I'm not necessarily opposed to the idea of using the RPC, I just
> > figured it probably wouldn't be that hard to get at least a tiny
> > libcriu going that would do what I needed.
> 
> In that case we'd have to solve the naming problem. E.g. right now
> libcriu.so contains the C RPC client, and functions like cr_dump() and
> cr_restore() just wrap the RPC request and talk to service.

Right, I'd think it would make sense to have two .sos, one with just
the RPC stuff, and one with the in-process stuff (which would then
contain most of criu).

> Another thing to solve is the variety of arguments criu accepts. It
> will not be possible to make cr_dump() to accept the fixed amount of
> args, since we add new quite often.

For this I think you could just re-use the same CriuOpts structure
that the RPC uses.

> Next, existing cr_dump() accepts pid == 0 which means "dump the caller".
> With cr_dump() being not RPC but direct code execution the self-dump
> will not work.
> 
> Also we have the notorious "root-only" limitation -- a lot of the API
> criu uses are protected with CAP_SYS_ADMIN (non user-ns) and alike.
> I'm not sure how useful this would be.

Yeah, this is the sticky part :(

> If we will want to let non-root use criu in this mode, then the most
> interesting thing is the security. If the process that calls "dump" is
> not root and puts images into the place where it can modify them, then
> restore from those would be too dangerous -- we will have to check
> that what we restore was not modified to raise the privileges.
> 
> Other than this, lib/ stuff is LGPL whilst the rest of the code is GPL
> and it would be nice to keep it GPL-ed.
> 
> Do you have ideas what to do with the above? Maybe it's worth refining
> the rpc-service model to be more handy that it is now?

Yes, the point about root that you and Ruslan brought up is one I
hadn't thought of, which sort of defeats the purpose of this. I think
it is probably best just to extend the RPC and require a CRIU service
to be running.

Thanks!

Tycho