[lxc-devel] Anybody looked at unshare(2)?
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:
> 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://email@example.com/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?
I am trying to push to mainstream the CLONE_NEWPID with unshare, but
honestly that sounds weird ...
CLONE_NEWUSER relies on copy_process to copy_cred, we don't use this
code path for unshare.
More information about the lxc-devel