From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 17 Dec 2004 15:24:56 +0530
From: Martin C.Atkins <martin_ml@parvat.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Acme mailreader - now: User mode filesystems in linux
Message-Id: <20041217152456.3f377069.martin_ml@parvat.com>
In-Reply-To: <20041217102526.0b64d965.martin_ml@parvat.com>
References: <3e1162e6041216070874f424e5@mail.gmail.com>
	<9ccf822edf0a9a77c141ae47312638dd@collyer.net>
	<20041217102526.0b64d965.martin_ml@parvat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 19cf93e8-eace-11e9-9e20-41e7f4b1d025

Of course, nothing I wrote in the previous message avoids (l)unix's
limitations regarding mount, etc. Nor does it allow users to write
their own fileservers (without opening up various security holes, and
having root access).

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.

When the user runs a program that wants to serve a filesystem, it attaches to
the daemon, which creates $HOME/mnt/servicename, and forwards all
requests for this directory hierarchy to the program. Replies are
adjusted to be consistent with security - setuid bits removed, ownership
forced to the user, etc., and sent back to the kernel.
When the program terminates, the daemon cleans up, and removes servicename.

Advantages over just hacking mount to allow anyone to mount anything on $HOME/mnt:

1) We don't need a /dev/cfsN for every filesystem, just one for each
concurrent user. Also client fileserving programs don't have to
compete to allocate /dev/cfsN's - which would need some sort of
setuid - only the daemons do this.

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

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)

4) The user-filesystem-daemon can clean up when/if a fileserver crashes.

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.

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

Disadvantages:
1) greater overhead - each fileserving message has to make the extra hops
from daemon to fileserver program, and back.

2) Complexity?

3) Others...?


The same approach would probably also work (better, easier?) with
p9fs - but some of the advantages might already have been solved
there, in other ways.

What do people think?

Martin
-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}