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

Andrew Vagin avagin at parallels.com
Wed May 14 02:48:32 PDT 2014


On Wed, May 14, 2014 at 12:12:00AM -0700, Allan Cecil wrote:
> Greetings,
> 
> I am working on implementing CRIU support for the nethack-tas-tools project (located at https://gitorious.org/nethack-tas-tools/).  In this scenario, an unprivileged user needs to be able to use Python RPC calls to checkpoint an instance of NetHack running in a screen session and restore it later.  What I've discovered is that the RPC call does not seem to properly support the --shell-job option on restore.  Here is an example where my process tree looks like this:
> 
> 13582 ?        Rl     0:17 gnome-terminal
> 13587 ?        S      0:00  \_ gnome-pty-helper
> 13588 pts/16   Ss     0:00  \_ bash
> 19203 pts/16   S+     0:00  |   \_ screen
> 19204 ?        Ss     0:00  |       \_ SCREEN
> 19205 pts/18   Ss     0:00  |           \_ /bin/bash
> 19369 pts/18   S+     0:00  |               \_ /home/tas/mainline/nethack-3.4.3
> 
> The target application is pid 19369, an instance of NetHack running in a screen session.  I have the following dump script which can be found in full at https://gitorious.org/nethack-tas-tools/mainline/source/6b0b272134fefe2e127f2182e2a2ab74e8d30d82:scripts/criuDump.py
> 
> req = rpc.criu_req()
> req.type = rpc.DUMP
> req.opts.pid = int(pid)
> req.opts.leave_running = False
> req.opts.shell_job = True
> req.opts.log_level = 4
> req.opts.log_file = 'dump.log'
> 
> When I run this script outside of screen it properly creates a directory named 19369 and kills the process, leaving screen running.  I then connect to the screen session and execute the following restore script which can be found in full at https://gitorious.org/nethack-tas-tools/mainline/source/6b0b272134fefe2e127f2182e2a2ab74e8d30d82:scripts/criuRestore.py
> 
> req = rpc.criu_req()
> req.type = rpc.RESTORE
> req.opts.shell_job = True
> req.opts.log_level = 4
> req.opts.log_file = 'restore.log'
> 
> This script always responds with a failure such as Error (tty.c:1218): tty: Standard stream is not a terminal, aborting.  This seems to imply that the --shell-job option is not being respected on an RPC restore, but this is just a guess on my part.  So far, I have been unable to find a way for an unprivileged user can restore an application into screen.  I have also found no way for an unprivileged user to restore a screen session itself, as it always fails due to UID security violations.  I have been unable to get any success by modifying the suid bit either, as that also complains about security violations.

A session can be only inherited, so shell-job doesn't have sense for
RPC. 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

Thanks.

> 
> Do you have any suggestions on how I can work past this problem?  I can be reached here at ac at sonic.net or as dwangoAC in #criu on IRC.  Thanks in advance,
> 
> A.C.
> ******
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu


More information about the CRIU mailing list