[Devel] Re: [RFC][PATCH 1/2] Deny CLONE_PARENT|CLONE_NEWPID combination

Sukadev Bhattiprolu sukadev at linux.vnet.ibm.com
Thu Jun 18 15:28:31 PDT 2009


Eric W. Biederman [ebiederm at xmission.com] wrote:
| Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com> writes:
| 
| > Deny CLONE_PARENT|CLONE_NEWPID combination.
| >
| > CLONE_PARENT was probably used to implement an older threading model.
| 
| Yes it was.
| 
| > If so, for consistency with CLONE_THREAD, the CLONE_PARENT|CLONE_NEWPID
| > combination should also fail with -EINVAL.
| 
| CLONE_THREAD can not work with CLONE_NEWPID because the processes share
| a signal queue.
| 
| I can see a similar argument going for CLONE_SIGHAND even though there is not
| as much sharing there.  I don't see how CLONE_PARENT could cause any harm.
| Without CLONE_SIGHAND.

It does not cause any harm. Only reason to disable CLONE_PARENT, at least for
now, is the confusing semantics (from users pov) and the process-tree model
and the usefulness (if CLONE_PARENT is only used in old threading model, the
needs of such an application acting as container-init is not clear).

Should we disable CLONE_SIGHAND in addition to CLONE_PARENT or just
CLONE_SIGHAND ?
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list