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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
