[CRIU] Can't launch unshare with -U or -r as unprivileged user

[Christopher Covington]

Hi Allan,

On 06/04/2014 01:46 AM, Allan Cecil wrote:
> Greetings,
> 
> I am still working toward using CRIU for the nethack-tas-tools project but I'm
> continuing to run into various problems when running CRIU as an unprivileged
> user.  With the fixes from earlier it is now possible for me to use the Python
> RPC script I mentioned before to checkpoint a screen session.  Unfortunately,
> restoring it is hit and miss, and often fails with various problems such as
> the PID not being the expected PID.  Cyril suggested compiling and using the
> latest unshare and passing in something along the lines of this: unshare
> -uimpn -- bash -c "(bash)"
> 
> Unfortunately, this fails on unshare from util-linux 2.24.903-56ce because
> virtually all of the flags require root privileges.  The manpage talks about
> using -U and -r instead to allow unshare to run without resorting to sudo
> (which is not available to the unprivileged user account in use).  The issue
> is unshare -U or unshare -r always fails with the following error message:
> unshare: unshare failed: Invalid argument
> 
> My question is, do I need to compile unshare (util-linux from git) with a
> particular flag to allow the -U option to work?  Should I be doing something
> else entirely, such as figuring out some way to carefully craft a sudo
> exception to allow an unprivileged user to do this (and if I go that
> direction, is there a way to do it and maintain a sense of security in the
> system)?  Better question - will the -U -r flags allow an unprivileged user to
> execute at least the -p flag without being in sudoers, or am I trying
> something impossible?
> 
> I have lots of questions but I'll keep investigating in the meantime.  Thanks
> in advance,

I've been using `unshare -fp` as root (with some light patches to CRIU that I
need to rebase and resubmit), but I gave the command a try as a regular user
on my Linux 3.2.0 x86_64 box, and reproduced your "Invalid argument" error.
This was my test case:

unshare -fp -- echo hello

With strace I see:

unshare(0x20000000 /* CLONE_??? */) = -1 EINVAL (Invalid argument)

According to the system call man page [1], this should indicate "An invalid
bit was specified in _flags_", rather than insufficient privileges (which
would return EPERM). Indeed, when I run it with sudo I get the same error.

1. http://man7.org/linux/man-pages/man2/unshare.2.html

CLONE_NEWPID (0x20000000) was added in
30e49c263e36341b60b735cbef5ca37912549264 which `git describe --contains` tells
me was included in v2.6.24-rc1, so a 3.2 kernel should have it. This led me to
check the kernel configuration. I've got CONFIG_PID_NS=y.

It appears there have been numerous patches since the initial addition of
CLONE_NEWPID tweaking unshare behavior with regard to the flag. My best guess
is that at least one of them is necessary for things to work. As root on a
3.15 ARM kernel I get no errors from `unshare -fp -- echo hello`.

What is your kernel version? Does -fp or -p work for you as root?

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.