On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
> On 4/19/05, Al Viro <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
> > > The motivation behind this patch is to make private namespaces more
> > > accessible by allowing their creation at mount/bind time.
> > >
> >
> > *UGH*
> >
> > So what happens to those who happen to share task->fs with the parent?
> >
>
> Okay, I'll admit to being a bit too hasty with pushing out that patch
> - I was being particularly myopic looking for a solution only for a
> command-line mount. Are you generally opposed to new namespace
> creation at mount time or just my slimy hack? A shared task->fs seems
> like something which could be easily checked against and disallowed.
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).
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".
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.
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...
-
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
