[CRIU] RPC support for --shell-job missing on restore

Pavel Emelyanov xemul at parallels.com
Thu May 15 06:59:48 PDT 2014


On 05/15/2014 02:25 AM, Allan Cecil wrote:
> On 05/14/2014 06:03 AM, Pavel Emelyanov wrote:
> ~snip~
> 
>>>
>>> A session can be only inherited, so shell-job doesn't have sense for RPC.
>>
>> Yes. More exactly -- if we make RPC respect --shell-job at restore time the
>> session and stdios will be inherited from criu-service daemon, not from the
>> SCREEN process.
>>
>> Do I understand it correctly, that you want to restore your process back as
>> a child and session member of the SCREEN?
>>
>>> You can set SUID bit for the criu binary and execute it directly.
>>>
>>> A bit more info you can find here:
>>> http://lists.openvz.org/pipermail/criu/2014-March/013257.html
>>
>> I agree. If it's possible to just run criu restore from screen, then it will
>> do the trick, but in that case you will get this process hierarchy:
>>
>> SCREEN
>>  `- criu restore
>>      `- your-restored-app
>>
>> Thanks,
>> Pavel
>>
> 
> Thank you very much for your reply.  To provide more context, think of this as an attempt to provide snapshotting for video games.

:)

> For now, I'm confining this to one very specific game, namely NetHack.  NetHack is entirely terminal-based and is fine running
> inside of screen (but it must be launched from a "real" terminal).  The end goal is for the user to be able to hit a keystroke 
> and checkpoint their state, continue on, and later hit a keystroke and restore back to the previous state (with a menuing system

I'd like to notice here, that right now this is only possible if you terminate the whole existing process and
restore one back from scratch using criu. However, we have a feature called "applying images" (http://criu.org/Applying_images)
With it you will not have to kill the original process and the revert-back should become MUCH faster.

> used to determine which state to restore back to).  I have this functionality working today using KVM as part of the
> nethack-tas-tools project, but CRIU looks like the better / cleaner approach.
> 
> My limitations are that the target user must NOT have root access.  This is for a wide variety of reasons, mostly centered around
> the fact that the user account is shared with multiple people.  I am OK with setting the suid bit on criu (and in fact I have
> already done so).  I started down the RPC path because there was Python support and it did not require root, but as you pointed
> out this is apparently a known limitation on restoring.  I'm actually OK with having the process hierarchy you showed as I assume

You might b einterested in the --exec-cmd option for criu. It causes criu to call execv() on whatever you want after
restore thus making _your_ code control the restored processes.

> that would still work.  Unfortunately, even if I set the suid bit and attempt to restore from the command line I still get denied
> bgecause the UID / GID doesn't match.

Can you shed more light on this? We tried to make it work like -- if we have images for user X, then if we restore from 
them from suid-ed criu and the user that does so is X as well, then we allow for that. Has that get broken?

> Do you have any suggestions for getting around this problem?  I'm more than willing to test
> specific scenarios and reply back with my results.  Thanks,

Thanks,
Pavel


More information about the CRIU mailing list