[lxc-devel] Anybody looked at unshare(2)?

Rob Landley rlandley at parallels.com
Wed Feb 23 20:52:27 UTC 2011

On 02/23/2011 03:40 AM, Daniel Lezcano wrote:
> On 02/23/2011 09:53 AM, Daniel Lezcano wrote:
>> On 02/23/2011 05:22 AM, Rob Landley wrote:
>>> It looks like clone flags aren't the only way to create a new namespace,
>>> any existing process can move to a new namespace via unshare(2).
>>> This sounds like you could fairly easily make a super_chroot() function
>>> that does most of the container stuff.  The hard part would be doing
>>> mount points, device setup, and TTY I/O.  (How much of this requires a
>>> host daemon?  I still haven't properly investigated how the current
>>> container TTY stuff behind lxc-console works...)
>> The problem with unshare is you can not create a new pid namespace.
> Neither a new user namespace.

The unshare(2) man page currently says it works with CLONE_NEWNS.  You
say it doesn't work with CLONE_NEWPID or CLONE_NEWUSER.  Looking at the
clone(2) man page, that leaves CLONE_NEWIPC, CLONE_NEWNET, and
CLONE_NEWUTS unresolved as to whether or not they work wiht unshare().

By the way, the clone(2) man page has no mention of CLONE_NEWUSER.  For
Michael's benefit I refer to:


Other question for Michael: should we have a containers(7) page?
Between http://lxc.sourceforge.net/ and
http://lxc.sourceforge.net/man/lxc.html we probably have a good start on
the material, but I'd like to add in the implemention bits from
http://lxc.sourceforge.net/index.php/about/kernel-namespaces/ and
http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg00582.html and
http://lwn.net/Articles/266426/ and so on...

I also note that our current kernel-namespaces page doesn't mention
CLONE_NEWNS which clones filesystem namespaces so each process can have
its own mount trees (and then the shared subtrees stuff adds mount flags
on top of those clone flags to control visibility).  I can add it to my
todo list...

Going forward, the commit adding CLONE_NEWUSER:


Just said "unshare is not included in this patch", not that there's a
major reason it couldn't be done.  Should I take a poke at this?  Is
there a major design reason that unshare(CLONE_NEWPID) can't convert the
current process to virtual PID 1 for its new namespace?


More information about the lxc-devel mailing list