Re: -mm -> 2.6.13 merge status (fuse)

Andrew Morton
2005-06-22T10:28:42Z

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/?)