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

[Miklos Szeredi <miklos@szeredi.hu>]

We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking.  Comments (either
way) are appreciated.

Here's my side of the story:

FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be used in the traditional way, but
that is uncontroversial and I'm not going to detail it here).  The
philosophy behind this is that sometimes it's very convenient if a
program can have a filesystem as it's _output_.

Examples are:

  - tar, zip, rar, etc[1] filesystem

  - ftp[2], ssh[3], etc filesystem

  - cvs[4], svn, etc filesystem

The common theme is that what you usually perform with some
specialized command can equally well (or sometimes better) be
performed with all the generic tools there are for file searching,
viewing, etc.

For example, the ftp and sftp commands actually give you a simulated
filesystem with a very limited shell (some variants have improved the
"simulation" by adding filename completion, etc).

With FUSE you can have the real thing and use your favourite tools on
remote or archived files.  I think this fits in very well with the
"everything is a file" UNIX philosophy.

To allow this to work in the most convenient and secure way the
following must be satisfied:

  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]

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

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

These are solved by:

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

  2) Use nosuid,nodev mount options

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

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

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

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.

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.

OK, open the flamethrowers!

Miklos

[1] http://www.inf.bme.hu/~mszeredi/avfs/ (CVS version required for
FUSE support)

[2] http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=132803

[3] http://fuse.sourceforge.net/sshfs.html

[4] http://cvsfs.sourceforge.net/

[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea.  E.g. root squashing by NFS servers
has a similar affect.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/