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

[Eric Van Hensbergen]

On 6/22/05, Pavel Machek <pavel@xxxxxx> wrote:
> >
> > I think that's a rather severe statement.   I don't see allowing user
> > mounts damaging standard UNIX system semantics as long as certain
> > rules are followed.   After all, user-mounts and private name spaces
> > are what the original authors of UNIX went on to develop.
> 
> Well, but notice how it is called "Plan 9", not "Unix" :-). The
> "certain rules" are rather tricky to enforce... btw any ideas how
> Plan 9 solves problems around user-mounts? Does it allow it at all?
> 

I agree the rules can be tricky, but I think we can start with
something ultra-conservative (but not as ultra-conservative as no user
mounts) and work from there.

Plan 9 does indeed allow (in fact in many ways it depends on) user
mounts.  There are a number of answers for how it gets around some of
the sticky issues -- some of those may be applicable in UNIX-style
systems, while others most likely don't apply.

The ones that don't apply:
(a) Plan 9 has no root user, nor does it have a concept of
setuid/setgid -- this solves a lot of problems, but isn't practical in
UNIX environments.
(b) Plan 9 cluster environments typically have user-controller
terminals and shared centralized resources (cpu servers, file servers,
etc.)  Users have more or less complete control over their local
workstation (which includes their name space) -- and they can import
resources/services from shared servers (where they have less/no
control).  Critical services, such as authentication, are hosted on a
remote server protected from normal users.  While this sort of
environment can be set up using UNIX systems -- its probably not
practical for most folks.

The ones that do apply:
(c) Private Name Space - by default, every new process in Plan 9 gets
a private name space inherited from its parent.  This means that any
user mounts will be in their own private name space and not interfere
with system tasks or other users.  As I've stated, I think this has
direct application in UNIX environments.  We may not go to the extreme
of making CLONENS the default for new threads, but I think it should
be easy enough to enforce unprivileged mounts be in a non-global name
space.
(d) For situations in which sharing a name space is desirable, the
name space is re-exported through a global handle (/srv in Plan 9's
case) so that a user can mount instances of his private name space in
other threads -- or he can set permissions on the handle so it may be
used by other users.  This re-export is done using the 9P protocol
(although if re-exporting to the same system it short-circuits to just
function calls within the OS).  The 9P layer adds a certain level of
security to just allowing name spaces to be accessed/mounted directly
- of course it also adds a bit of overhead.  We are currently looking
at this sort of implementation in the v9fs 2.1 release.

Given that (a) & (b) aren't practical in UNIX environments, I think a
reasonable set of restrictions (some of which were suggested by
Miklos) can be used to maintain integrity:
1) only allow user's to mount/bind on directories/files where they
have unconditional write access.
2) enforce NOSUID mount options on user-mounts

If you combine these two restrictions with only allowing unprivileged
mounts in private name space I think you get 90% there.  The only
thing left to resolve is the best way to allow sharing private name
spaces between threads/users -- and I still view this as more of
extended functionality than a hard-requirement.

I'm giving a talk at OLS overviewing my perspective on the barriers
and solutions.  My motivation was to try and get some
dialog/compromise/closure on some of the user-space mount and private
name space issues.  Hopefully some of the stake-holders will attend.

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