Re: FUSE merging?

Miklos Szeredi
2005-07-03T13:25:07Z

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