Return to BSD News archive
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!inferno.mpx.com.au!goliath.apana.org.au!news.syd.connect.com.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!ncar!uchinews!not-for-mail From: cdjeris@midway.uchicago.edu (Christopher Jeris) Subject: Re: Ideal filesystem X-Nntp-Posting-Host: quads.uchicago.edu Message-ID: <Dpx5xn.DB5@midway.uchicago.edu> Summary: Proposed semantics Sender: news@midway.uchicago.edu (News Administrator) Organization: The University of Chicago References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <31719AE4.7EAF32DF@lambert.org> Date: Mon, 15 Apr 1996 19:53:47 GMT Lines: 97 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21381 comp.unix.bsd.freebsd.misc:17340 Ok, try the following semantics on for size. They're probably equipotent with, or a slight extension of, something that already exists in the common UNIX fs---but I'm not sure that the best criterion for judging an exper- imental concept is ease of implementation in terms of existing concepts. I think something with some of the characteristics of personal views and registries can be built, and made to support "nomadic computing", relatively easily. Again, I apologize if I'm rehashing concepts which are already taken for granted by everyone. * The file structure is a bunch of trees whose node types alternate, level by level, between "files" and "forks". A file is a nonempty set of forks (we require that a file contain an "Info" fork encoding various kinds of bookkeeping information about itself). One type of fork is a "group" or "directory", which is a (possibly empty) set of files. A file may belong to more than one group. If you like, you can regard the top level of the structure as a group fork containing every top-level object on the system. Each file also has some way of knowing all the groups to which it belongs. Objection: Why make this alternation? You can build a structure that quacks just like this one with ordinary files and directories. Answer: We make a distinction between data objects which can stand on their own and those which can't. Ideally I would like every data object which might ever be copied or transferred by itself to be able to identify itself, explain its origin, format and purpose. Thus forks: at the level of file operations (as opposed to running programs I guess---it would be clumsy to demand an extensive ID attachment to every intermediate-computation squirt?) a fork may not be transferred alone. They are elements of file structure which are worth isolating a little, but not a lot. Of course this *can* be implemented by writing utilities to run on top of a UNIX file system (and I'll probably do that to test these concepts out) but that isn't the point, I think. * We distinguish "views" or "privilege levels", to which the closest thing in UNIX may be the user id, but a given user may possess several and be able to switch between them. I'm not really sure what to call them because they can be used both as views and as privilege restrictions. Each file has associated with it a mapping of view/user ids to privileges, of which one is *visibility*. The file may, if desired, inherit its privilege map (with modifications or not) from its group. This may lead to interesting things like "Binaries:emacs" (emacs in its hat as a global user program, member of group Binaries) having different access privileges than "Emacs:emacs" (emacs as member of the group Emacs which contains the software package, and may not be accessible to everybody). In other words, files in multiple groups may inherit their privileges from the group used to access them. I don't know if this is a semantic/security mess or not, I just think it might be interesting. The point of visibility being a privilege is that one can prepare a nice group configuration for ordinary users to see, interact with, and customize. Then, when they call support, one can tell them "Okay, switch to the <System Maintenance> view, and do this and this and this," and if they have messed with the almighty System Maintenance view then on their heads be it. Obviously you would have to be careful to see that all their customizations are not smacked by the changes you make from the Maintenance view. * A file which references other files (say, a program which gets a library name substituted into it by a Makefile) must put those references in a special fork, say FileRef. The preferred way to reference them is by a group-relative address, i.e., by an address in a group to which both referrer and referee belong, and which forms the logical unit for transfer from place to place. (Emacs's source, living in "...:Emacs:src:...", will reference library files as "^Emacs:lib:..." denoting "search upward for a group named Emacs, then go down by lib, etc.".) One builds smart editors to do these things :) When a file or bunch of files is transferred, the copy agent fixes up all the references, asking for help if necessary---sort of like linking a program. This seems to confer the ability for nomadic computing, at least between trusted machines: just ask someone else to serve you a given group, fix up all the links, and go. For security perhaps you could save long characteristic values for all the "big stuff you're not going to take with you," and compare yours with theirs. Objection: Too much meta-data. Answer: Well, yeah, I guess. But transparently migrating structured data across physical systems just seems to require a lot of meta-data and relative reference to me. * Finally, the concept of registries was what inspired this whole thing for me---all you have to do is create well-defined top- or near-top-level groups, like "Binaries" and "SystemConfig" and the like; then whenever you install a program make the binary a member of "Binaries" and so on. Just like a link in UNIX, really, except that when the file is destroyed elsewhere (say you execute "destroy Emacs" to kill the whole Emacs group) it vanishes from everywhere, rather than the link being broken in one place but remaining in another. No mess, no fuss. One can then transparently maintain subgroups within "Binaries", say "Admin" for system administration and stuff, so that it's still "Binaries:reboot" to everyone, but inaccessible or invisible to everyone who doesn't have access to "Binaries:Admin". This would be done by putting a cookie in reboot's Info fork saying not "Inherit privileges from accessing group", but absolutely "Inherit privileges from Binaries:Admin, of which I am a member", and then in Binaries:Admin, saying "Invisible to everyone not in group Admin" or some such. Anyway. How's all this stuff look to people who actually know something about how to build a good filesystem ? Christopher Jeris c-jeris@uchicago.edu University of Chicago Math