Messages in this thread | | | Date | Mon, 11 Apr 2005 14:17:17 -0400 | From | Daniel Jacobowitz <> | Subject | Re: [RFC] FUSE permission modell (Was: fuse review bits) |
| |
On Mon, Apr 11, 2005 at 05:56:09PM +0200, Miklos Szeredi wrote: > > > 3) No other user should have access to files under the mount, not > > > even root[5] > > > > > [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. > > > > Could you explain a little more? I don't see the point in denying > > access to root, but I also can't tell from your explanation whether you > > do or not. > > Fuse by default does. This can be disabled by one of two mount > options: "allow_other" and "allow_root". The former implies the > later. These mount options are only allowed for mounting by root, but > this can be relaxed with a configuration option.
So the behavior that Cristoph was objecting to here is in fact configurable?
> > I don't really see the point of this restriction, anyway. Could you > > explain why this shouldn't be a matter of policy, and kept out of the > > kernel? Have the userspace file servers default to putting restrictive > > permissions on mounts unless requested otherwise. > > That's an option. However you can't restrict root that way, and you > need an extra directory, since permissions on the mountpoint are > ignored after the mount.
No, you need the userspace daemon to set the permissions on the root directory of the new mount restrictively. What am I missing?
> Restricting root is needed, so that a sysadmin won't accidently go > into a user's private mount (e.g. sshfs to some machine to which the > sysadmin otherwise has no access). Root can still gain access by > doing 'su me', but at least he will have a bad conscience. This is > not such a stupid idea as it first sounds IMO, and by default all NFS > servers exhibit a similar behavior (root squashing).
Root squashing is actually a much less obnoxious restriction. It means that local uid 0 doesn't automatically correspond to remote uid 0.
> > > 4) Access should not be further restricted for the owner of the > > > mount, even if permission bits, uid or gid would suggest > > > otherwise > > > > Similar questions. > > This behavior can be disabled by the "default_permissions" mount > option (wich is not privileged, since it adds restrictions). A FUSE > filesystem mounted by root (and not for private purposes) would > normally be done with "allow_other,default_permissions".
But why does the kernel need to know anything about this? Why can't the userspace library present the permissions appropriately to the kernel? I'm going to be pretty confused if I see a mode 666 file that I can't even read. So will various programs.
Except for the allow_root bits, I think that having userspace handle the issue entirely would cover both objections.
> Does this answer your questions?
More or less.
-- Daniel Jacobowitz CodeSourcery, LLC - 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/
| |