[CRIU] Towards an in-process libcriu

[Pavel Emelyanov]

On 07/17/2014 05:32 PM, Tycho Andersen wrote:
> 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).

Yup, this would work.

>> 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.

Here's the comparison of APIs we have -- CLI, RPC and C:
http://criu.org/API_compliance

It reflects the recent git head and hopefully it contains all the 
stuff we have :)

Thanks,
Pavel