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)
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/

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