Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Jamie Lokier]

Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem.  It also helps not cluttering the
> global namespace with user-local mounts
> 
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private namespaces can become really useful.
> > 
> 
> I'd like to talk about this a bit more and start driving to a solution
> here.  I've been looking at the namespace code quite a bit and was
> just about to dive in and start checking into adding/fixing certain
> aspects such as stackable namespaces, optional inheritence (changes in
> a parent namespace are reflected in the child but not vice-versa),
> etc.
> 
> One aspect I was thinking about here was a mount flag that would give
> you a new private namespace (if you didn't already have one) for the
> mount (and I guess that would impact any subsequent mounts from the
> user in that shell).  Another option would be a 'newns' style
> system-call, but I'm generally against adding new system calls.
> 
> Shared subtrees are a tricky one.  I know how we would handle it in
> V9FS, but not sure how well that would translate to others
> (essentially we'd re-export the subtree so other user's could mount it
> individually -- but that's a very Plan 9 solution and may not be what
> more UNIX-minded folks would want -- we also need to improve our own
> server infrastructure to more efficiently support such a re-export).
> 
> So, to sum up I think private namespaces is the right solution, and
> I'd rather put effort into making it more useful than work-around the
> fact that its not practical right now.

Have a chat with Al Viro, who has already done some work on shared
mounts and subtrees I think.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/