[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUGd-+Z4tWF3uJa18eKgK+GcMaOp0Jm4dtQm7E=wz1NMg@mail.gmail.com>
Date: Thu, 22 Aug 2013 10:59:58 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Brad Spengler <spender@...ecurity.net>,
Colin Walters <walters@...hat.com>,
Pavel Emelyanov <xemul@...allels.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] pidns: fix vfork() after unshare(CLONE_NEWPID)
On Thu, Aug 22, 2013 at 10:09 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> 8382fcac "pidns: Outlaw thread creation after unshare(CLONE_NEWPID)"
> nacks CLONE_VM if the forking process unshared pid_ns, this obviously
> breaks vfork:
>
> int main(void)
> {
> assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0);
> assert(vfork() >= 0);
> _exit(0);
> return 0;
> }
>
> fails without this patch.
>
> Change this check to use CLONE_SIGHAND instead. This also forbids
> CLONE_THREAD automatically, and this is what the comment implies.
>
> We could probably even drop CLONE_SIGHAND and use CLONE_THREAD,
> but it would be safer to not do this. The current check denies
> CLONE_SIGHAND implicitely and there is no reason to change this.
Acked-by: Andy Lutomirski <luto@...capital.net>
although...
>
> Reported-by: Colin Walters <walters@...hat.com>
> Signed-off-by: Oleg Nesterov <oleg@...hat.com>
> ---
> kernel/fork.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index e23bb19..86f5376 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1173,10 +1173,10 @@ static struct task_struct *copy_process(unsigned long clone_flags,
> return ERR_PTR(-EINVAL);
>
> /*
> - * If the new process will be in a different pid namespace
> - * don't allow the creation of threads.
> + * If the new process will be in a different pid namespace don't
> + * allow the creation of threads, or share the signal handlers.
...how about "If the new process will be in a different pid namespace,
don't allow it to share a thread group or signal handlers with the
parent"?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists