From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755569Ab3HWOma (ORCPT ); Fri, 23 Aug 2013 10:42:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755311Ab3HWOm3 (ORCPT ); Fri, 23 Aug 2013 10:42:29 -0400 Date: Fri, 23 Aug 2013 15:59:23 +0200 From: Oleg Nesterov To: Andy Lutomirski Cc: Andrew Morton , "Eric W. Biederman" , Linus Torvalds , Brad Spengler , Colin Walters , Pavel Emelyanov , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 3/3] fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks Message-ID: <20130823135923.GA16773@redhat.com> References: <20130822170939.GA20296@redhat.com> <20130822171004.GA20324@redhat.com> <20130822181536.GA22995@redhat.com> <20130822183250.GA23769@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/22, Andy Lutomirski wrote: > > On Thu, Aug 22, 2013 at 11:32 AM, Oleg Nesterov wrote: > > On 08/22, Andy Lutomirski wrote: > >> > >> On Thu, Aug 22, 2013 at 11:15 AM, Oleg Nesterov wrote: > >> > > >> > 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. > >> > >> Is this -stable-worthy? > > > > Honestly, I do not know. I do not want to abuse -stable, and I will > > sleep better if this patch won't go into the stable trees ;) > > > > OTOH, I think that at least 1/3 is probably -stable material... Since > > I am going to send v2, I would not mind to add stable@vger.kernel.org > > if both you and Eric agree. > > This may allow creation of a process with tgid and pid in different > pid namespaces. If so, I have no idea what the consequences would be. and share the parent with the creator. Not good. But probably not too bad, one can abuse ->pidns_install() anyway, create a child in another ns, exit. Like it or not but pid_ns is "special" and you even sent the patch to reflect this sad^W fact. Anyway. The main point of this patch is the consistency (plus imho it cleanups/simplifies the code). Both CLONE_NEWPID and "task_active_pid_ns() != pid_ns" create a task in another namespace, we should use the same restrictions. And you seem to agree with this change, can I take it as your ack ? I am going to preserve your acks in 1-2 and resend. Oleg.