Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760545AbZJMQ3G (ORCPT ); Tue, 13 Oct 2009 12:29:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760532AbZJMQ3E (ORCPT ); Tue, 13 Oct 2009 12:29:04 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:33394 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760531AbZJMQ3C (ORCPT ); Tue, 13 Oct 2009 12:29:02 -0400 Date: Tue, 13 Oct 2009 11:28:18 -0500 From: "Serge E. Hallyn" To: Pavel Emelyanov Cc: Sukadev Bhattiprolu , linux-kernel@vger.kernel.org, Oren Laadan , "Eric W. Biederman" , Alexey Dobriyan , Andrew Morton , torvalds@linux-foundation.org, mikew@google.com, mingo@elte.hu, hpa@zytor.com, Nathan Lynch , arnd@arndb.de, peterz@infradead.org, Louis.Rilling@kerlabs.com, roland@redhat.com, kosaki.motohiro@jp.fujitsu.com, randy.dunlap@oracle.com, linux-api@vger.kernel.org, Containers , sukadev@us.ibm.com Subject: Re: [RFC][v8][PATCH 3/10]: Make pid_max a pid_ns property Message-ID: <20091013162818.GA13416@us.ibm.com> References: <20091013044925.GA28181@us.ibm.com> <20091013045041.GC28435@us.ibm.com> <4AD47C1F.7040703@openvz.org> <20091013152453.GA9994@us.ibm.com> <4AD4A676.3010603@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD4A676.3010603@openvz.org> 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 Content-Length: 1517 Lines: 37 Quoting Pavel Emelyanov (xemul@openvz.org): > > This patch isn't a core part of the clone_with_pid functionality, > > just something Eric has asked for. So I don't object to dropping > > it. But I disagree with Alexey's claim that this isn't a namespace > > property. It should be. > > OK > > >> frankly I don't see the reason for doing so. Why should we? > >> Especially taking into account, that we essentially cannot > >> change thin in the namespace level 3 and deeper? > > > > What do you mean by that? With this patchset we're not, it's > > true, but we trivially can - even now, userspace can simply not > > give the container CAP_SYS_ADMIN or write access to the sysctl > > so they can't do any more CLONE_NEWPIDS or change the sysctl. > > It's a misprint - I meant "level 2 and deeper". Sysctl is > only pointing at the init_pid_ns variable. Right, and I'm saying that's to be fixed up as with all other containerized sysctl's. You're right that this patch doesn't solve that problem, but you seem to be arguing that it bc it's not done in this patch, we should act as though it can't be done. But again, maybe we're best off dropping this patch (sorry, Suka, I had suggested you add it...) and focusing on the rest of the set for now. thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/