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

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

Eric W. Biederman [ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org] wrote:
| Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 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 ?