lkml.org 
[lkml]   [2005]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] FUSE permission modell (Was: fuse review bits)
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/

\
 
 \ /
  Last update: 2005-04-11 20:27    [W:0.145 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site