From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 17 Dec 2004 14:13:35 -1000 From: Tim Newsham 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 In-Reply-To: <20041217152456.3f377069.martin_ml@parvat.com> Message-ID: References: <3e1162e6041216070874f424e5@mail.gmail.com> <9ccf822edf0a9a77c141ae47312638dd@collyer.net> <20041217102526.0b64d965.martin_ml@parvat.com> <20041217152456.3f377069.martin_ml@parvat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Topicbox-Message-UUID: 1a52a09e-eace-11e9-9e20-41e7f4b1d025 > 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.