lkml.org 
[lkml]   [2005]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] FUSE permission modell (Was: fuse review bits)
    From
    Date
    > > > >   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 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 21:14    [W:4.075 / U:0.472 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site