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

[Miklos Szeredi <miklos@szeredi.hu>]

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