Re: FUSE merging?

[Frank van Maarseveen]

On Sun, Jul 03, 2005 at 08:16:37AM +0200, Miklos Szeredi wrote:
> > After some thinking, the whole "not allowing namespace differences
> > based on user id" philosophy is unenforcable and not even true sometimes
> > nowadays. Think NFS: have a look at the unfsd server, you'll be surprised
> > what it can do. Think any other networked file system exported by a
> > machine with an unusual disk file-system underneath. IIRC ncpfs does
> > this on the server based on access and thus based on uid.
> 
> Hmm, do you mean returning different directory contents based on uid?

	http://clusternfs.sourceforge.net

Don't ask me how this plays with the dcache.

> > The thing is, root rules the _local_ part of the name space. So it should
> > make a _huge_ difference if FUSE can fiddle with that or only with what's
> > below the leaf nodes.
> 
> I don't really understand what you mean by "local".

The opposite of "local" is "remote", i.e. networked filesystems:

	mount foo:/bar /usr/src/bar

/, /usr and /usr/src are stored on a local disk. /usr/src/bar/* is not.
Namespace invariance can be guaranteed for the "/usr/src" part. Not for
anything below unless you control the peer.

> 
> The problem with this leaf node philosophy, is that it's not really
> consistent.  You can ensure that a mountpoint is a leaf node at mount
> time, but you cannot force it to remain a leaf node after the mount.  So
                   ^^^
                 inserted by me

ok, I just remembered that any process with an open directory handle
could still fchdir() underneath. I think the leaf node enforcing is
possible but it is indeed a bit more complicated.

(Hmm, it's a bit bizarre but could you mount FUSE on, for example, a
 named pipe and change it into a directory?)

> I don't see why this check at mount time would make _any_ difference.

It should be possible to do audits on local filesystems, e.g. by:

	find / /home /var -xdev ....

This can be done as root but sometimes you may want to do this with the
uid/gid of a specific user, for safety or for checking what the user
actually can access or damage. And that won't work as expected when the
user places a FUSE mount on top of his own login directory. But I don't
think leaf node enforcing is required from a security point of view. This
is the only thing I could come up with.

IMHO The namespace argument against FUSE is weak for multiple reasons. The
only variancy I see is when crossing the mount point. And that disappears
once EACCES is returned when non-ptraceable processes try to cross it.
But that's not really acceptable (see previous audit case) unless FUSE
refuses to mount on non-leaf dirs.

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