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

From: Jamie Lokier (jamie_at_shareable.org)
Date: 04/11/05

  • Next message: Daniel Jacobowitz: "Re: [RFC] FUSE permission modell (Was: fuse review bits)" 
    Date:	Mon, 11 Apr 2005 19:22:57 +0100
To: Miklos Szeredi <miklos@szeredi.hu>

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

  • Next message: Daniel Jacobowitz: "Re: [RFC] FUSE permission modell (Was: fuse review bits)"

    Relevant Pages

    • Re: How to mount ext3 so the files belong to a specific user?
      ... Are you aware that you only need to tweak the permissions to your liking ... Just create an ext2/3 filesystem, mount it as root and then change ...
      (Debian-User)
    • Re: Setting [u|f]mask on a bind mount
      ... The files can't have different permissions in different places. ... Note that the filesystem mount options will remain the same as ... You would have to change the original mount point options in order to ... The directory would need to be on its own filesystem. ...
      (Debian-User)
    • Re: [opensuse] Problem writing to drive shared by Vista and Suse 10.3
      ... when booted into opensuse only root can write to the ... filesystem and chmod has no effect. ... The only method to change the permissions is to change them at mount time, ...
      (SuSE)
    • Re: Unable to authenticate after upgrading
      ... >permissions are affected and the system will not reboot. ... >nuts until I unmounted the filesystems and saw that the mount point ... >directories had no world read or execute access. ... mount point's permissions are invisible after the filesystem is mounted. ...
      (comp.security.ssh)
    • Re: mount() function problem !
      ... mount() attaches the filesystem specified by source (which is often a device name, ... point within a file system. ... details of the options available for each filesystem type. ... Specifies the journalling mode for file data. ...
      (comp.lang.c)