Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Jamie Lokier <jamie@shareable.org>]

Miklos Szeredi wrote:
>   1) User must not be able to modify files or directories in a way
>      which he otherwise could not do (e.g. mount a filesystem over
>      /bin)
> 
>   2) Suid and device semantics should be disabled within the mount
> 
>   3) No other user should have access to files under the mount, not
>      even root[5]

Why?  I can see plenty of uses where I want a filesystem generated by
one user to be accessible by other users.  That policy should not be
hard-coded into the kernel.  It might be an option.

>   4) Access should not be further restricted for the owner of the
>      mount, even if permission bits, uid or gid would suggest
>      otherwise

Why?  Surely you want to prevent writing to files which don't have the
writable bit set?  A filesystem may also create append-only files -
and all users including the mount owner should be bound by that.

>   5) As much of the available information should be exported via the
>      filesystem as possible

This is the root of the conflict.  You are trying to overload the
permission bits and uid/gid to mean something different than they
normally do.

While it's convenient to see some "remote" information such as the
uid/gid in a tar file, are you sure it's a good idea to break the unix
permissions model - which will break some programs?  (For example, try
editing a file with the broken semantics in an editor which checks the
uid/gid of the file against the current user).

For most virtual filesystems, the "remote" information does not map to
uid/gid in a particularly natural way anyway.  So it seems odd to want
to break the unix permissions model just so that a small _subset_ of
virtual filesystems can use stat() as a way to get a bit of
information out, when other virtual filesystems (e.g. webdavfs) can't
put meaningful information in there, and would benefit from normal
unix permissions instead.

>   1) Only allow mount over a directory for which the user has write
>      access (and is not sticky)

Seems good - but why not sticky?  Mounting a user filesystem in
/tmp/user-xxx/my-mount-point seems not unreasonable - provided the
administrator can delete the directory (which is possible with
detachable mount points).

>   2) Use nosuid,nodev mount options

Of course.  Ideally, make sure they appear to be set in /proc/mounts.

(root (or equivalent) should be able to create virtual filesystems
without these options, but probably they should be set by default even
for root, and clearable using suid,dev).

>   3) In permission method of FUSE kernel module compare fsuid against
>      mounting user's ID, and return EACCES if they are not equal.

Bad.  How do I, user A, then create a virtual filesystem which I want
user B to be able to access?

>   4) The filesystem daemon does not run with elevated permissions.
>      The kernel doesn't check file more in the permission method.

I like the idea that the fs daemon doesn't need elevated permissions.

>   5) The filesystem daemon is free to fill in all file attributes to
>      any (sane) value, and the kernel won't modify these.

Dangerous, because an administrative program might actually trust the
attributes to mean what they normally mean in the unix permissions model.

> The debated part is 3) and 4), namely that normal permission checking
> based on file mode is bypassed, and the mounting user has full
> permission to all files, while other users have none.
> 
> This feature has been in FUSE from the start and thus has been very
> well tested in real world scenarios.  Also I have thought a lot about
> how this could pose any kind of security threat, and as yet found no
> such possiblity.

Ok, but why do you prevent the useful behaviour of allowing access to
other users, when I want that?  For example, I might export my current
project's database as a filesystem that I _want_ other users to be
able to read.

> Despite this Christoph feels this behavior is unacceptable for a
> filesystem, and wants me to remove this feature before merging FUSE
> into mainline.  I try to be open to ideas, but also feel strongly that
> this is the Right Way, so I won't give up easily.

I agree with Christoph.  It is a huge deviation from the unix
permissions model -- and it seems to prevent some useful applications
of FUSE so it's not clear why you want it.

-- Jamie