From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Brad Spengler <spender@grsecurity.net>,
Colin Walters <walters@redhat.com>,
Pavel Emelyanov <xemul@parallels.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks
Date: Thu, 22 Aug 2013 20:15:36 +0200 [thread overview]
Message-ID: <20130822181536.GA22995@redhat.com> (raw)
In-Reply-To: <CALCETrU9D59MqxPm2SNegPFH_+gpPfoQJkD2E2Q8zjJ94QhLDg@mail.gmail.com>
On 08/22, Andy Lutomirski wrote:
>
> On Thu, Aug 22, 2013 at 10:10 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > do_fork() denies CLONE_THREAD | CLONE_PARENT if NEWUSER | NEWPID.
> >
> > Then later copy_process() denies CLONE_SIGHAND if the new process
> > will be in a different pid namespace (task_active_pid_ns() doesn't
> > match current->nsproxy->pid_ns).
> >
> > This looks confusing and inconsistent. CLONE_NEWPID is very similar
> > to the case when ->pid_ns was already unshared, we want the same
> > restrictions so copy_process() should also nack CLONE_PARENT.
> >
> > And it would be better to deny CLONE_NEWUSER && CLONE_SIGHAND as
> > well just for consistency.
> >
> > Kill the "CLONE_NEWUSER | CLONE_NEWPID" check in do_fork() and
> > change copy_process() to the same check along with nsproxy->pid_ns
> > we already have.
>
> Did the old code actually prevent clone(CLONE_PARENT | CLONE_NEWPID)?
> The new code explicitly does, and that looks like a good thing.
Yes. Before this patch do_fork() did:
if (clone_flags & (CLONE_NEWUSER | CLONE_NEWPID)) {
if (clone_flags & (CLONE_THREAD|CLONE_PARENT))
return -EINVAL;
}
however, let me repeat, CLONE_PARENT after unshare(CLONE_NEWPID) was
allowed. With this patch CLONE_PARENT is nacked in both cases.
Oleg.
next prev parent reply other threads:[~2013-08-22 18:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-22 17:09 [PATCH 0/3] namespaces && fork fixes/cleanups Oleg Nesterov
2013-08-22 17:09 ` [PATCH 1/3] pidns: fix vfork() after unshare(CLONE_NEWPID) Oleg Nesterov
2013-08-22 17:59 ` Andy Lutomirski
2013-08-22 18:22 ` Oleg Nesterov
2013-08-22 17:10 ` [PATCH 2/3] pidns: kill the unnecessary CLONE_NEWPID in copy_process() Oleg Nesterov
2013-08-22 18:05 ` Andy Lutomirski
2013-08-22 17:10 ` [PATCH 3/3] fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks Oleg Nesterov
2013-08-22 18:10 ` Andy Lutomirski
2013-08-22 18:15 ` Oleg Nesterov [this message]
2013-08-22 18:29 ` Andy Lutomirski
2013-08-22 18:32 ` Oleg Nesterov
2013-08-22 19:11 ` Andy Lutomirski
2013-08-23 13:59 ` Oleg Nesterov
2013-08-23 17:42 ` Andy Lutomirski
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=20130822181536.GA22995@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=spender@grsecurity.net \
--cc=torvalds@linux-foundation.org \
--cc=walters@redhat.com \
--cc=xemul@parallels.com \
/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.