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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Miklos Szeredi <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux