From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 18 Dec 2004 18:05:10 +0530 From: Martin C.Atkins 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: <20041218180510.63765240.martin_ml@parvat.com> In-Reply-To: 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: 1a7fe9b4-eace-11e9-9e20-41e7f4b1d025 Gosh - lots of comments.. On Fri, 17 Dec 2004 08:44:52 -0700 (MST) "Ronald G. Minnich" wrote: > > so presumably he felt Coda could be improved upon. > > As peter used to put it, 5KLOC (intermezzo) was in his mind better than > 500KLOC (coda). He brought both file systems to fruition. Good reason! But the kernel modules were only a small fraction of that total size, right? > yeah, intermezzo limped along for 5 years, never quite worked, then died. > But the kernel->user interface of intermezzo is perfectly usable. Sounds > like you've gotten far with coda, so this is just an FYI. Pity abut Intermezzo - trying it (for it's designed purpose) was on my todo list... Thanks for your assessment of the Intermezzo kernal->user interface. I've often wondered if I could have been used it for my driver itstead of coda, but like you say, I've gotten thus far with Coda... > in the game, and got to the point where I could boot a linux node with > imezzo as the root file system. That was interesting. Sounds fun! On Fri, 17 Dec 2004 13:41:09 +0000 Derek Fawcus wrote: > > 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) > > So while it's running, I can use gdb to attach to it and get around any security > it's trying to enforce (turn setuid back on, change ownership to root, etc). Good point! I guess it would have to stay setuid to avoid that - pity. Is there another way of stopping gdb, et al? I see that EPERM on ptrace can be caused if the debuggee is already being debugged. Is there any way that a program can ptrace itself, just to stop anyone else from debugging it? (1/2 :-)) On Fri, 17 Dec 2004 09:42:15 -0500 Karl Magdsick wrote: > > 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. > > Why are the setuid meta-daemons needed? You'll want security/sanity > checks within the kernel code anyway, so the main reason for the > setuid meta-daemons is creating(??/destroying??) device files. It > seems that you could get around this by using one device file for > everyone, which brings us to... > > Why N different devices? The kernel can distinguish between open > filehandles for /dev/cfs and use an array, tree, or map of structs to > [ plus more good points] Two reasons: 1) I was trying to see how far we could get without having to change *anything* in the stock linux kernel distribution. This makes distributing the result much easier... 2) When you mount a coda device, you are talking to the fileserver that opened that coda device. If you multiplexed the device, you would have to have some other way of saying *which* user-mode fileserver you were trying to mount. Otherwise, I agree. > As mentioned in another post, you can prevent device files and setuid > executibles in non-root owned filesystems and allow any user process > to mount a fs on any mount point they own. Yes, and these mechanisms are [probably best. > The kernel needs its own cleanup code (what if one of the per-user > filesystem meta-daemons crashes?) and security/sanity checks (only If the per-user filesystem meta-daemons crashes, then, like I said, with coda, the kernel is pretty safe already. However I'd like the user's view of things to be cleaned up too. and: On Fri, 17 Dec 2004 14:13:35 -1000 (HST) Tim Newsham wrote: > 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 future, I totally agree. Unfortunately my requirement was for something that would work with all the linux systems already out there. > 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. So it now seems - I was just thinking aloud, and the result was interesting, and informative for me. > 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. Yes. The lack of close messages (until recently) in nfs, certainly restricted its usefulness for this purpose though. > V9fs already provides a useful protocol. No disagreements there, however there have already been discussions in other threads pointing out that V9fs doesn't (yet?) have messages for linux things that Plan 9 doesn't have - such as symlinks. > Restrictions as to where mount points could be placed could be > put in any setuid binary that mediates user mounts. I was trying to get around the restriction that user mounts could only be under $HOME/mnt, imposed by my scheme. Given access to a more general mount, I don't see any reason to restrict it unnecessarily! Thanks all for interesting feedback! Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin}