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

Daniel Lezcano daniel.lezcano at free.fr
Wed Feb 23 21:26:48 UTC 2011


On 02/23/2011 09:52 PM, Rob Landley wrote:
> 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:
>
>    http://lxc.sourceforge.net/index.php/about/kernel-namespaces/
>
> 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:
>
>    http://lwn.net/Articles/237662/
>
> 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?

I am trying to push to mainstream the CLONE_NEWPID with unshare, but 
honestly that sounds weird ...

https://lists.linux-foundation.org/pipermail/containers/2011-February/026612.html

CLONE_NEWUSER relies on copy_process to copy_cred, we don't use this 
code path for unshare.




More information about the lxc-devel mailing list