Eric W. Biederman [ebiederm@xxxxxxxxxxxx] wrote: | Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
