Re: FUSE merging?

[Miklos Szeredi]

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

But here the decision on what to return is in the _server_.  There's
nothing magic about that.  It's as if it was N different servers for N
different clients, only more effective.

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

I think what you call namespace invariance is basically true for all
existing filesystems.  There could be a filesystem which returns
different directory contents based on whatever it wants, but it can't
return a different "dentry" for the same name.

So file/directory _content_ can be made to vary, but the namespace
itself can't.

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

[well corrected :)]

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

No.  Fusermount checks file type and refuses the mount if there's a
mismatch (and it protects against races by mounting on '.' for
directories, and on '/proc/self/fd/X' for regular files).

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

But note, that running with the uid/gid of the user exposes the
auditing script to manipulation (kill, ptrace) by the user.  Running
with changed fsuid/fsgid is OK though.

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

OK, from the auditing POV, there's a slight hole in unprivileged
mounts.  But I don't think this is grave, since it's not so hard to
hide any sensitive data from such scripts anyway (keeping data in
memory, or keeping a file descriptor to an unlinked file, etc).

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

Yes, but still this is just a difference in permission, and not a
difference in namespace.

> But that's not really acceptable (see previous audit case) unless FUSE
> refuses to mount on non-leaf dirs.

I don't think the audit case is important.  It's easy to work around
it manually by the sysadmin, and for the automatic case it doesn't
really matter (as detailed above).

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