Re: [RFC] FUSE permission modell (Was: fuse review bits)

From: Daniel Jacobowitz (dan_at_debian.org)
Date: 04/11/05

  • Next message: Shawn Starr: "[2.6.12-rc2][suspend] resume occuring twice before suspend to suspend-to-disk" 
    Date:	Mon, 11 Apr 2005 15:22:23 -0400
To: Miklos Szeredi <miklos@szeredi.hu>

    On Mon, Apr 11, 2005 at 09:10:46PM +0200, Miklos Szeredi wrote:
    > > 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.

    That's considerably less obnoxious, because such directories are
    comparatively rare; most files, root can still read. There are still
    a couple unintuitive cases where root has less privelege than a
    particular non-root user, of course. But your model gives root
    normally fewer privileges than the user that mounted th e FS.

    > > 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.

    So why not make default_permissions a feature of the userspace?

    > > 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.

    The permissions exposed by the FUSE layer apparently don't correspond
    to what local users can do with them. That's the problem here. It may
    be that I'm completely misunderstanding you - but from what you've
    described, the userspace daemon can mark a file's permissions as 666,
    and then with allow_other and allow_root off no one else will be able
    to read it, despite those permissions.

    > > 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.

    I think we've got a boundary problem here. You are exposing some
    arbitrary, user-supplied values in the permissions, and then performing
    sanity checks at access time; I'm suggesting performing the sanity
    checking on the other side, when the permissions are supplied to the
    kernel by the daemon.

    Why would it be less useful to show files that have been "created" by a
    user as owned by that user? Or files that the user has requested no
    other users be able to write as unwritable by group/other? Sure, it
    makes your tarfs a little less mapped onto the tar file. But that's
    one of the recurring objections to implementing archivers as
    filesystems: the ownership in the archive is _not_ relevant to the
    mounted copy. 

    -- 
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/
  • Next message: Shawn Starr: "[2.6.12-rc2][suspend] resume occuring twice before suspend to suspend-to-disk"

    Relevant Pages

    • Re: kmail lost old folders/emails
      ... den 02.04.2004 schrieb John Walsh um 11:57: ... > read it (this is as root). ... If you did not mean that please explain what the permissions are. ... latest FC1 kernel .2174 as far as I know. ...
      (Fedora)
    • Re: Xterm Hangs - Possible scheduler defect?
      ... > If root has explicitly stated that the thread in question is the highest ... I think what we have are the need for two levels of applications: ... wishes to preempt all other userspace applications. ... OK being preempted by the kernel when the kernel needs to do work. ...
      (Linux-Kernel)
    • Re: [RFC] FUSE permission modell (Was: fuse review bits)
      ... >> root is denied all access. ... and the kernel checks the permission. ... The userspace can't enforce the permissions. ...
      (Linux-Kernel)
    • Re: Question in regards root
      ... now I can no longer login as root, it comes up and says "login: ... I am wondering if there is a command to get around this to become root ... so I can make the changes to the permissions etc? ... This error is returned by the auditonsystem call when your kernel ...
      (freebsd-questions)
    • Re: Problem setting up NFS on Ubuntu
      ... I have installed Ubuntu ... > I used System - Administration - Synaptic Package Manager to include NFS ... Should I be using the GUI, and if so, how do I do that as root, ... and doesn't change the permissions displayed by ls -l ...
      (comp.os.linux.setup)