From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call Date: Wed, 20 Apr 2005 08:14:48 -0500 Message-ID: References: <20050419222324.GM13052@parcelfarce.linux.theplanet.co.uk> <20050420033304.GO13052@parcelfarce.linux.theplanet.co.uk> Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from wproxy.gmail.com ([64.233.184.204]:30310 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261618AbVDTNOt convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2005 09:14:49 -0400 Received: by wproxy.gmail.com with SMTP id 50so182193wri for ; Wed, 20 Apr 2005 06:14:49 -0700 (PDT) To: Al Viro In-Reply-To: <20050420033304.GO13052@parcelfarce.linux.theplanet.co.uk> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 4/19/05, Al Viro wrote: > On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote: > > On 4/19/05, Al Viro wrote: > > a) ability to create a private namespace without forking anything - sure, > that would be useful. However, that's not something I would push into > mount(2) (already overloaded to hell and back). > That's fair, just though it might be easier to slide in than a new system call. Should have known better -- sliding things in is never a good idea. > > There used to be a kinda-sorta agreement on a new syscall: > unshare(bitmap) > with arguments like those of clone(2). That's not just for namespaces - > e.g. you might legitimately want to unshare VM in a thread and leave the > rest alone. Or unshare ->fs (i.e. uncouple cwd from the rest of group). > > Most of the code is already there - do_fork() has to do such stuff anyway. > So how about adding sys_unshare(flags) that would do that job? Flags would > correspond to those of clone(2), except that all these guys would be > "what do we unshare" instead of "what do we leave shared". > Okay, I'll try to work something up today and post a straw man here. > > b) I _really_ don't like the idea of messing with the parent. Make it > a shell builtin if you want to affect shell behaviour; the same reason > why cd is a builtin and not an external command. > Yeah, that was really slimy, just wanted something that would be more accessible to end users without having to affect changes to lots of applications. A somewhat less slimy method would be to expose something in /proc, but I suppose that is a much more theologically charged option. > c) I would be really, really careful with implications of "let user > do whatever he wants" - that certainly should include bindings and > that can create heaps of fun for suid stuff. More comments when > I get around to digging through FUSE thread... I agree, but I want to understand all the issues and see if we can work out a solution which gives the user some ability to leverage mount/bind in private namespaces. I am trying to get more of a Plan 9 like environment under Linux, but understand the existence of a root uid will require a lot more restrictions. See my comments in the later portions of the FUSE thread on a user-mount-permissions file that would allow admins to define policies on what and where users could mount/bind (and with what flags). -eric