[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