Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!gatech!swrinde!howland.reston.ans.net!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: Tue, 16 Apr 1996 15:05:14 -0700
Organization: Me
Lines: 244
Message-ID: <3174199A.7837FA99@lambert.org>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <31719AE4.7EAF32DF@lambert.org> <Dpx5xn.DB5@midway.uchicago.edu>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21632 comp.unix.bsd.freebsd.misc:17562
Christopher Jeris wrote:
]
] 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 experimental concept is ease
] of implementation in terms of existing concepts.
Here, here!
] 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.
It's not taken for granted by everyone, or they wouldn't be
trying to pound it all into the same shape of sack they've
always used.
[ ... description of n-connectedness in set relationships elided ... ]
] 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.
Yes, yes, yes!
] 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.
Exactly. The point is a unified API which must be used by
every application at the user/FS (kernel) interface level.
If it is possible for me to subvert this with an assembler and
knowlege of the source code for the OS, then it is not possible
to rely on it: the host synchronization issues impede this type
of approach: you are left with the same problems as a hosted
file system for a network server when you have local users on
the server at the same time.
Further, if we want to tag things to FS events, the events *must*
be in kernel space.
One example is a user space directory browser. We want the browser
to recieve notification when the directory contents have changed
so that it can update the view onto the directory for the user.
Another example is a file which has event flags set by another
file as a result of a compound document architecture implementation;
two exmaples are a spreadsheet with overall budget derived from
the encapsulation of departmental budgets, which in turn derive
from workgroup budgets. Another example is a company "policy
and procedures" manual which is always up-to-date because
changes in departemental policy are immediately reflected in the
overall manual.
NeXT called such object "Live Links".
] * 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.
Inheritance is atricky issue. A group-based scheme can not
handle issues of both forward and reverse inheritance without
propagating "implied priveledge records". It is very usage
dependent as to how fast this would grow to be computationally
unmanageable.
One example of forward inheritance is the "read-only" mount
attribute, which is inherited below the mountpoint. We could
easily envision apply this on a non-mount-point directory
and having it inherited down.
Now say the same directory hierarchy used a reverse inheritance
exception model (ie: NetWare Trustees, for example).
NetWare trustee rights imply access to parent objects through
reverse inheritance. In such a forward inheritance group
scheme, it would be impossible to determine user rights to
any given intermediate FS object in the hierarchy without
exhaustively iterating all inferior nodes in the hierarchy
at any point in the hierarchy. This is analogous to the
"path hashing" problem discussed previously, except that
it is not an order 2 geometry -- it's an order N geometry.
Reverse inheritance of rights identifiers for implied rights
to objects ("you can see this directory because you can see
some object inferior to this directory") requires that the
act of right inheritance propagation be tightly bound to the
event establishing or destroying the rights chain. If you
delete the file, or change the rights on it, the event must
be handled as a transaction -- NOT in user space.
A traditional presentation is not capable of yielding seperate
records for implied and explicit rights in a combined inheritance
model -- only a combined rights mask... which is insufficient
for rights manipulation, only sufficient for rights enforcement.
Further, a user space library for manipulation of this particular
attribution can not guarantee atomicity in the transaction,
when the transaction on the file itself implies subsequent
transactions all the way to the FS root.
Finally, the per-rights overhead in supplying access controls
to the rights themselves makes the records much larger than
necessary (or desirable: each incremental increase in storage
size for an atribute is multiplied by the depth in the overall
hierarchy in an implied inheritance scheme).
] 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.
Yes. There is a need for view cannonization, and it is expected
that the applications themselves must operate within the cannonical
view to avoid the user's view damaging their ability to function.
Because the user can not see the configuration file does not
mean that the application will have the same restriction.
For this reason, I really believe the concept of "personal view"
to be a shell or visual browser abstraction, not any real
storage artifact of any kind.
] 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.
Trancendentality of links. 8-). For instance, if I move the
system configuration file, and it is visible to my view, my view
won't change even though the location of the view target has.
] 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.
Careful. I believe self-consistency to be an issue for the
application programmer to resolve (hopefully with library
support, if necessary).
The danger in making the "exporter/importer" resolve conflicts
is the same human intervention problem which made niload/nidump
a bad idea on NeXT systems. If a machine can synchronize two
sets of dependent information, it should do so instead of
causing a human to do it.
A FS event of "password file has changed" could have easily been
implemented in NeXTStep to cause the "niload" to occur
automatically.
] * 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.
This is the Microsoft approach to the resoloution of "the path
problem", as discussed previously. It has some merits, but also
some drawbacks.
It seems to me that you could get near-identical capabilities
with system, group, and session logical names, in combination
with variant symbolic links.
One example of this is the idea "default GIF viewer" when you
delete the user's choice off the system. Typically, you would
*not* want to remove the broken link; instead you would want
to cause access to the broken link to trigger a "new link
selection". You could call "GIF viewers" a group if you wanted,
in this context, but it seems to be one level of abstraction
above what you were using as "group".
The cookies would not be necessary because of the inheritance
rules for logical names.
The drawbacks in the Microsoft implementations as they currently
exist is that there is still "promiscuous" (or "loose host binding")
access availabel to delete resource out from under the registry.
There is also no concept of system, group, and user registries --
only system, and there is no protection on its use.
Personally, I'll probably stick to implementing the foundation
technologies on which abstract groups, inherited rights, reverse
inherited rights, and low cost attributes for FS objects can be
implemented. When you start imposing structure, you start
limiting choices (like the structure of file-as-directory does).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.