Re: [RFC][PATCH 2/2] Prevent container-inits from using CLONE_PARENT

[Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

| Again, strange but harmless.

Right nothing broken, just trying to disable the strangeness till usage
becomes clear.

| 
| > To keep pid namespace semantics simple, prevent container-inits from using
| > CLONE_PARENT at least until we have a better understanding of CLONE_PARENT
| > and pid-namespace interactions.
| 
| Yes, perhaps makes sense.
| 
| > --- linux-mmotm.orig/kernel/fork.c	2009-06-17 18:23:23.000000000 -0700
| > +++ linux-mmotm/kernel/fork.c	2009-06-17 19:17:54.000000000 -0700
| > @@ -974,6 +974,14 @@ static struct task_struct *copy_process(
| >  	if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & CLONE_VM))
| >  		return ERR_PTR(-EINVAL);
| >
| > +	/*
| > +	 * To keep pid namespace semantics simple, prevent container-inits
| > +	 * from creating siblings.
| > +	 */
| > +	if ((clone_flags & CLONE_PARENT) &&
| > +			is_container_init(current) && !is_global_init(current))
| 
| Both is_ checks are not right afaics. There are per-thread. This means
| that container-init can do clone(CLONE_THREAD), and then this thread
| does CLONE_PARENT and fools copy_process().

Good point. Should check the tgid.
| 
| As for !is_global_init(). I never understood what should we do if the
| global init does CLONE_PARENT, this attaches another process to swapper,
| not good.

Agree, like I replied to Eric, I just was not sure there were any
existing users of CLONE_PARENT :-(

I could make a separate patch in this set to just disable CLONE_PARENT for
global init.