All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Alexey Dobriyan
	<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [RFC][PATCH] Deny CLONE_PARENT|CLONE_NEWPID|CLONE_SIGHAND combination
Date: Sat, 11 Jul 2009 12:39:44 -0700	[thread overview]
Message-ID: <20090711193944.GA32330@us.ibm.com> (raw)
In-Reply-To: <20090702115740.GB3552-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Oleg Nesterov [oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
| On 07/01, Sukadev Bhattiprolu wrote:
| >
| > Deny CLONE_PARENT|CLONE_NEWPID|CLONE_SIGHAND combination.
| >
| > CLONE_PARENT was used to implement an older threading model.  For consistency
| > with the CLONE_THREAD check in copy_pid_ns(), disable CLONE_PARENT and
| > CLONE_SIGHAND with CLONE_NEWPID, at least until the required semantics of
| > the pid namespaces are clear.
| >
| > Changelog[v2]:
| > 	[Eric Biederman] Disable CLONE_SIGHAND also ???
| >
| > Signed-off-by: Sukadev Bhattiprolu <sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
| > Acked-by: Roland McGrath <roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
| > ---
| >  kernel/pid_namespace.c |    2 +-
| >  1 file changed, 1 insertion(+), 1 deletion(-)
| >
| > Index: linux-mmotm/kernel/pid_namespace.c
| > ===================================================================
| > --- linux-mmotm.orig/kernel/pid_namespace.c	2009-06-30 23:01:09.000000000 -0700
| > +++ linux-mmotm/kernel/pid_namespace.c	2009-06-30 23:49:06.000000000 -0700
| > @@ -118,7 +118,7 @@ struct pid_namespace *copy_pid_ns(unsign
| >  {
| >  	if (!(flags & CLONE_NEWPID))
| >  		return get_pid_ns(old_ns);
| > -	if (flags & CLONE_THREAD)
| > +	if (flags & (CLONE_THREAD|CLONE_PARENT|CLONE_SIGHAND))
| >  		return ERR_PTR(-EINVAL);
| 
| Still can't understand why CLONE_SIGHAND is forbidden...
| 
| CLONE_SIGHAND doesn't mean we share the signal queue, so what is
| the reason?

I don't have a convincing reason. We could disable just the
CLONE_NEWPID|CLONE_PARENT combination till we have a need for it. We
talked about removing CLONE_PARENT but backed-off since some application
may be using it. Disabling specific combinations like this (CLONE_NEWPID is
relatively a new flag) could make it a little easier to remove CLONE_PARENT
in the future.

Sukadev

WARNING: multiple messages have this Message-ID (diff)
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: roland@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com>,
	Oren Laadan <orenl@cs.columbia.edu>,
	serue@us.ibm.com, Alexey Dobriyan <adobriyan@gmail.com>,
	Containers <containers@lists.linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] Deny CLONE_PARENT|CLONE_NEWPID|CLONE_SIGHAND combination
Date: Sat, 11 Jul 2009 12:39:44 -0700	[thread overview]
Message-ID: <20090711193944.GA32330@us.ibm.com> (raw)
In-Reply-To: <20090702115740.GB3552@redhat.com>

Oleg Nesterov [oleg@redhat.com] wrote:
| On 07/01, Sukadev Bhattiprolu wrote:
| >
| > Deny CLONE_PARENT|CLONE_NEWPID|CLONE_SIGHAND combination.
| >
| > CLONE_PARENT was used to implement an older threading model.  For consistency
| > with the CLONE_THREAD check in copy_pid_ns(), disable CLONE_PARENT and
| > CLONE_SIGHAND with CLONE_NEWPID, at least until the required semantics of
| > the pid namespaces are clear.
| >
| > Changelog[v2]:
| > 	[Eric Biederman] Disable CLONE_SIGHAND also ???
| >
| > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com>
| > Acked-by: Roland McGrath <roland@redhat.com>
| > ---
| >  kernel/pid_namespace.c |    2 +-
| >  1 file changed, 1 insertion(+), 1 deletion(-)
| >
| > Index: linux-mmotm/kernel/pid_namespace.c
| > ===================================================================
| > --- linux-mmotm.orig/kernel/pid_namespace.c	2009-06-30 23:01:09.000000000 -0700
| > +++ linux-mmotm/kernel/pid_namespace.c	2009-06-30 23:49:06.000000000 -0700
| > @@ -118,7 +118,7 @@ struct pid_namespace *copy_pid_ns(unsign
| >  {
| >  	if (!(flags & CLONE_NEWPID))
| >  		return get_pid_ns(old_ns);
| > -	if (flags & CLONE_THREAD)
| > +	if (flags & (CLONE_THREAD|CLONE_PARENT|CLONE_SIGHAND))
| >  		return ERR_PTR(-EINVAL);
| 
| Still can't understand why CLONE_SIGHAND is forbidden...
| 
| CLONE_SIGHAND doesn't mean we share the signal queue, so what is
| the reason?

I don't have a convincing reason. We could disable just the
CLONE_NEWPID|CLONE_PARENT combination till we have a need for it. We
talked about removing CLONE_PARENT but backed-off since some application
may be using it. Disabling specific combinations like this (CLONE_NEWPID is
relatively a new flag) could make it a little easier to remove CLONE_PARENT
in the future.

Sukadev

  parent reply	other threads:[~2009-07-11 19:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  7:40 [RFC][PATCH] Deny CLONE_PARENT|CLONE_NEWPID|CLONE_SIGHAND combination Sukadev Bhattiprolu
2009-07-01  7:40 ` Sukadev Bhattiprolu
2009-07-02  1:31 ` Serge E. Hallyn
     [not found] ` <20090701074045.GA14595-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-07-02  1:31   ` Serge E. Hallyn
2009-07-02 11:57   ` Oleg Nesterov
2009-07-02 11:57 ` Oleg Nesterov
     [not found]   ` <20090702115740.GB3552-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-11 19:39     ` Sukadev Bhattiprolu [this message]
2009-07-11 19:39       ` Sukadev Bhattiprolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090711193944.GA32330@us.ibm.com \
    --to=sukadev-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.