Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen <ericvh@gmail.com>]

On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
> > On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> 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