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

Allan Cecil ac at sonic.net
Wed May 14 15:25:52 PDT 2014


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

A.C.
******


More information about the CRIU mailing list