lkml.org 
[lkml]   [2005]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/12/05, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > I think that would be _much_ nicer implemented as a mount which is
> > invisible to other users, rather than one which causes the admin's
> > scripts to spew error messages.
>>
> > Is the namespace mechanism at all suitable for that?
>
> It is certainly the right tool for this. However currently private
> namespaces are quite limited. The only sane usage I can think of is
> that before mounting the user starts a shell with CLONE_NS, and does
> the mount in this. However all the other programs he already has
> running (editor, browser, desktop environment) won't be able to access
> the mount.
>

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.

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

\
 
 \ /
  Last update: 2005-04-17 19:49    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site