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/
