[CRIU] Towards an in-process libcriu

[Pavel Emelyanov]

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.

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.

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.

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?

Thanks,
Pavel