lkml.org 
[lkml]   [2005]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] FUSE permission modell (Was: fuse review bits)
    From
    Date
    > I think that would be _much_ nicer implemented as a mount which is
    > invisible to other users, rather than one which causes the admin's
    > scripts to spew error messages.

    Spew is a strong word. It'll get a single EACCES at the mountpoint.
    The same is true for directories not accessible by 'nobody' under an
    NFS mount exported with root squash.

    > Is the namespace mechanism at all suitable for that?

    It is certainly the right tool for this. However currently private
    namespaces are quite limited. The only sane usage I can think of is
    that before mounting the user starts a shell with CLONE_NS, and does
    the mount in this. However all the other programs he already has
    running (editor, browser, desktop environment) won't be able to access
    the mount.

    Shared subtrees and more support in userspace tools is needed before
    private namespaces can become really useful.

    > It would also be nice to generalise and have virtual filesystems which
    > are able to present different views to different users. Can FUSE do
    > that already - is the userspace part told which user is doing each
    > operation?

    Yes.

    > With that, the desire for virtual filesystems which cannot be read
    > by your sysadmin (by accident) is easy to satisfy - and that kind of
    > mechanism would probably be acceptable to all.

    The problem is that this way the responsibility goes to the userspace
    program, which can't be trusted.

    Either the kernel has to enforce that uid/gid on each file are set to
    the mount owner, or the kernel has to enforce that no other user has
    access to the mountpoint. Some policy _must_ be kept in kernel.

    I think both these policies have valid uses, so I wouldn't want to
    limit FUSE to a single one. Hmm?

    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-12 08:19    [W:5.573 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site