> > > > 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?
Christoph was not objcting to lack of choice, rather the opposite. He
would like to have only the "allow_other" behavior.
> > > 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?
You are basically right. This would conflict slightly with 5) in that
the attributes of the root would be lost.
> > 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.
I don't agree that it's less obnoxious. Root squashing and a
restricted directory (-rwx------) would have exactly the same affect:
root is denied all access.
> > > > 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?
That is exactly what you should do if you use the default_permissions
options. You set the file mode, and the kernel checks the permission.
> I'm going to be pretty confused if I see a mode 666 file that I
> can't even read. So will various programs.
How would you get such I file? I don't understand.
> Except for the allow_root bits, I think that having userspace handle
> the issue entirely would cover both objections.
If I want to allow unprivileged users to be able to mount their
filesystems, then handling everything in userspace is not an option.
For example if you could mount a filesystem in which files have
user=root instead of your own user ID, you could probably confuse some
applications running as root, and cause information leak. That's
exactly why allow_root and allow_other are disabled for normal users.
The only safe option that I can imagine is that the kernel will reset
the user and group fields of the file attributes. This would again
require a kernel option, but would be far less useful IMO.
Thanks,
Miklos
-
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]
