Re: CLONE_PARENT after setns(CLONE_NEWPID)

2014-01-15 Thread Serge Hallyn
Quoting Christian Seiler (christ...@iwakd.de): > Eric W. Biederman writes: > >So hmm. > > > >Because it can do no harm, and because it is a regression let's remove > >the CLONE_PARENT check and send it stable. > > > >diff --git a/kernel/fork.c b/kernel/fork.c > >index 086fe73..c447fbc 100644 > >---

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2014-01-15 Thread Christian Seiler
Eric W. Biederman writes: So hmm. Because it can do no harm, and because it is a regression let's remove the CLONE_PARENT check and send it stable. diff --git a/kernel/fork.c b/kernel/fork.c index 086fe73..c447fbc 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1174,7 +1174,7 @@ static struc

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-08 Thread Oleg Nesterov
On 11/06, Eric W. Biederman wrote: > > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1174,7 +1174,7 @@ static struct task_struct *copy_process(unsigned long > clone_flags, > * do not allow it to share a thread group or signal handlers or > * parent with the forking task. >

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Christian Seiler
Hi there, Having used bash as an init process I know it can handle unexpeted children. However using CLONE_PARENT in this way still seems a little dodgy. Or am I misunderstanding why you are using CLONE_PARENT? Since I (re)wrote that part of LXC, I should perhaps clarify how that is used: In

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Serge Hallyn
Quoting Andy Lutomirski (l...@amacapital.net): > On Wed, Nov 6, 2013 at 2:50 PM, Eric W. Biederman > wrote: > > Oleg Nesterov writes: > > > >> Hi Serge, > >> > >> On 11/06, Serge Hallyn wrote: > >>> > >>> Hi Oleg, > >>> > >>> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : > >>> "fork: unify a

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Serge Hallyn
Quoting Eric W. Biederman (ebied...@xmission.com): > Oleg Nesterov writes: > > > Hi Serge, > > > > On 11/06, Serge Hallyn wrote: > >> > >> Hi Oleg, > >> > >> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : > >> "fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks" > >> breaks lxc-attac

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Eric W. Biederman
Serge Hallyn writes: > 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) There is nothing new the pid namespace adds to the pid namespace

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Andy Lutomirski
On Wed, Nov 6, 2013 at 2:50 PM, Eric W. Biederman wrote: > Oleg Nesterov writes: > >> 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 i

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Eric W. Biederman
Oleg Nesterov writes: > 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

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Serge Hallyn
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 >

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Andy Lutomirski
On Wed, Nov 6, 2013 at 12:06 PM, Oleg Nesterov wrote: > On 11/06, Andy Lutomirski wrote: >> >> On Wed, Nov 6, 2013 at 11:33 AM, Oleg Nesterov wrote: >> > Hi Serge, >> > >> > On 11/06, Serge Hallyn wrote: >> >> >> >> Hi Oleg, >> >> >> >> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : >> >> "for

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Oleg Nesterov
On 11/06, Andy Lutomirski wrote: > > On Wed, Nov 6, 2013 at 11:33 AM, Oleg Nesterov wrote: > > Hi Serge, > > > > On 11/06, Serge Hallyn wrote: > >> > >> Hi Oleg, > >> > >> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : > >> "fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks" > >> bre

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Andy Lutomirski
On Wed, Nov 6, 2013 at 11:33 AM, Oleg Nesterov wrote: > 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

Re: CLONE_PARENT after setns(CLONE_NEWPID)

2013-11-06 Thread Oleg Nesterov
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