Messages in this thread | | | Date | Wed, 22 Jun 2005 03:19:20 -0700 | From | Andrew Morton <> | Subject | Re: -mm -> 2.6.13 merge status (fuse) |
| |
Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > > > We could. But that would again be overly restrictive. The goal is to > > > > > make the use of FUSE filesystems for users as simple as possible. If > > > > > the user has to manage multiple namespaces, each with it's own > > > > > restrictions, it's becoming a very un-user-friendly environment. > > > > > > > > I'd have thought that it would be possible to offer the same user interface > > > > as you currently have with private namespaces. Hide any complexity in the > > > > userspace tools? Where's the problem? > > > > > > Sorry, I don't get it. > > > > I'm asking you to expand on what the problems would be if we were to > > enhance the namespace code as suggested. > > OK, what I was thinking, is that the user could create a new > namespace, that has all the filesystems remounted 'nosuid'. This > wouldn't need any new kernel infrastructure, just a suid-root program > (e.g. newns_nosuid), that would do a clone(CLONE_NEWNS), then > recursively remount everything 'nosuid' in the new namespace. Then > restore the user's privileges, and exec a shell. > > In this namespace the user could mount things to his heart's content. > He could mount over system directories or even the root directory, > without being able to do any harm. > > This is very nice, but a bit inpractical, since now all the other > programs of the user, his desktop environment, login shells etc. Won't > be able to see the userspace filesystems mounted in the private > namespace.
Yup, that's useless. That makes the whole CLONE_NEWNS idea unworkable, yes?
Have we exhausted the alternatives?
(If, as you say, v9fs and samba (did you mean smbfs/cifs?) want unprivileged mounts, shouldn't the code which you have there be moved out of fs/fuse/ and into fs/?) - 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/
| |