From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [RFC][PATCH 1/2] Deny CLONE_PARENT|CLONE_NEWPID combination
Date: Thu, 18 Jun 2009 15:28:31 -0700
Message-ID: <20090618222831.GA14063@us.ibm.com>
References: <20090618024743.GA31515@us.ibm.com>
	<20090618024934.GA31672@us.ibm.com>
	<m1d492jk0k.fsf@fess.ebiederm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <m1d492jk0k.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
List-Unsubscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.linux-foundation.org/pipermail/containers>
List-Post: <mailto:containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
List-Help: <mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=help>
List-Subscribe: <https://lists.linux-foundation.org/mailman/listinfo/containers>,
	<mailto:containers-request-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org?subject=subscribe>
Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "David C. Hansen" <haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>, Oleg Nesterov <oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>, Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
List-Id: containers.vger.kernel.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 ?