On 4/19/05, Al Viro <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
> > On 4/19/05, Al Viro <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
