Re: [9fans] Acme mailreader - now: User mode filesystems in linux

[Tim Newsham <newsham@lava.net>]

> However, thinking over lunch, I realised that there is a way of doing
> something quite nice (in the linux sense, if not the Plan 9 sense!) with
> what we already have.
>
> On login, each user starts a user-filesystem-daemon, which uses setuid
> to create a /dev/cfsN, if necessary, opens it to start serving, and
> mounts it on a conventional place: $HOME/mnt, say.
[...]

I think it would be better to just implement the v9fs protocol
and let users mount it in a similar way as nfs.  The v9fs layer
in the kernel would simply communicate the kernel filesystem requests
over some pipe to another machine (or the same machine) in much
the same way as nfs requests get sent out.  The layer could support
options (or strictly enforce) to disable setuid bits and/or file
ownership.  A setuid mounting utility that enforced any no-setuid
options could allow users to perform mounts.  Userland filesystems
could be implemented by providing a service that adheres to
the v9fs.

Adding a seperate userland demon that proxies a filesystem
protocol (probably the same one) through to the kernel seems
like an uneeded layer of complexity.

It seems like there are a lot of projects out there that have
interest in providing userland filesystems.  They typically use
nfs because its the easiest vector into the existing infrastructure.
V9fs would definitely fill a useful niche.


> 2) The user-filesystem-daemon only has to run as root during initialisation,
> everything else runs as the user.

A network daemon talking v9fs shouldn't impose any ownership
restrictions.  The restrictions should be imposed at mount time.

> 3) The user-filesystem-daemon can enforce file ownership (as the user) in
> the served directory hierarchy. It can also force off setuid bits, etc.
> Furthermore, users can only attach their fileservers to their own daemons!
> (A bit like per-process mount tables - of course, linux has this already, but
> not in a very user-friendly form)

This can be done in-kernel.  In fact, there are already options in
nfs to neuter suid bits, device nodes and provide user mappings.

> 5) Knowledge of the Coda protocol could be limited to the daemon, and a
> higher-level protocol used with the "real" fileservers. Thus we could move to
> other kernel mechanisms (e.g. fuse) if/when they become available.

V9fs already provides a useful protocol.

> 6) All user filesystems are under $HOME/mnt - symlinks could be used
> from elsewhere. (or is this a disadvantage?)

Restrictions as to where mount points could be placed could be
put in any setuid binary that mediates user mounts.

Tim N.