Subject: user-land file systems
To: None <tech-kern@NetBSD.ORG>
From: VaX#n8 <>
List: tech-kern
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:
1. compressed
2. encrypted
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 -
Deal with evil through strength, yet encourage good through trust.    - PGP me