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. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
