Quoting Oleg Nesterov (o...@redhat.com): > Hi Serge, > > On 11/06, Serge Hallyn wrote: > > > > Hi Oleg, > > > > commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : > > "fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks" > > breaks lxc-attach in 3.12. That code forks a child which does > > setns() and then does a clone(CLONE_PARENT). That way the > > grandchild can be in the right namespaces (which the child was > > not) and be a child of the original task, which is the monitor. > > Thanks... > > Yes, this is what 40a0d32d1ea explicitly tries to disallow. > > > Is there a real danger in allowing CLONE_PARENT > > when current->nsproxy->pidns_for_children is not our pidns, > > or was this done out of an "over-abundance of caution"? > > I am not sure... This all was based on the long discussion, and > it was decided that the CLONE_PARENT check should be consistent > wrt CLONE_NEWPID and pidns_for_children != task_active_pid_ns().
So apart from peers seeing the new task as having pid 0, and sigchild going to the grandparent, are there any other side effects? Is ptrace an issue? (I took a quick look but it doesn't seem like it) If not, then I very much think we should continue to allow this. -serge ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
