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

[Miklos Szeredi <miklos@szeredi.hu>]

> > > >  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.

Of course he can enter the private namespace immediately after login,
but then he won't be able to send mail for example, because 'sendmail'
could be suid-mail or whatever.

I think the following must be true, for a namespace environment to be
useful:

 1) All the processes should be able to access the same files
    (including new mounts)

 2) User should be able to run suid/sgid programs


If the suid/sgid programs want to access the contents of a userspace
filesystem, that's tough.  You can't have that, because it's insecure.
But experience shows that this isn't a problem.  The exception is the
'mount' program itself, and that is why I'm slowly working towards
making sys_mount() and sys_umount() unprivileged.

Miklos
-
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/