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

Allan Cecil ac at sonic.net
Wed May 14 00:12:00 PDT 2014


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.

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


More information about the CRIU mailing list