Subject: user-land file systems
To: None <tech-kern@NetBSD.ORG>
From: VaX#n8 <firstname.lastname@example.org>
Date: 06/17/1995 02:51:11
I've been thinking about Unix's strength centering around the file metaphor,
(and ppl's discontent with the SVR4 IPC interfaces), and came up with several
ideas for file systems:
3. concurrent versioning
4. tar archive (for transparency with ftpd, etc)
5. news or mail (e.g. each article is file, news hierarchy is directory hier)
This would require several generalizations; I'd like to see a non-root
mount with the necessary restrictions (nosuid, noexec, whatever)
(although from reading Bugtraq, I gather you have to be -real- careful.
I'd suggest making sure the user owned the mount point, not just checking
for r/w/no-suid access on it.) (nosuid because you don't want someone
mounting over /tmp, for example - one case where it's not always obvious)
Also, I'd like to see some kind of callback into user space (daemons?) to
handle userland debugging of filesystems. I know they'd be slower, but they'd
be less like to crash your system (and easier to debug), and there really
isn't any reason IMHO why a user can't access a file of hers as a fs hierarchy
of her own design if she really wants to. What do you people think?
I'm aware of the cfs (crypted file sys) design that uses NFS on a loopback
interface, but I think this is hideous, especially on a machine that wouldn't
otherwise be running NFS. And NFS has a history of being way insecure.
Disclaimer: I haven't considered all the ramifications; I may not be
qualified to do so anyway.
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - email@example.com
Deal with evil through strength, yet encourage good through trust. - PGP me