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

[Martin C.Atkins <martin_ml@parvat.com>]

Gosh - lots of comments..

On Fri, 17 Dec 2004 08:44:52 -0700 (MST) "Ronald G. Minnich" <rminnich@lanl.gov> 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 <dfawcus@cisco.com> 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 <kmagnum@gmail.com> 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 <newsham@lava.net> 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}