[cap-talk] Sharing with OS support - The Elephant System, inheritance

[Jed Donnelley]

At 02:55 AM 12/8/2006, Neal H. Walfield wrote:
 >At Tue, 05 Dec 2006 16:52:48 -0800,
 >Jed at Webstart wrote:
 > > At HP last Friday I mentioned a facility that we had at LLNL many
 > > years ago that I considered quite helpful/useful in bootstrapping
 > > sharing between people.  It had the following properties (sorry if
 > > this is a repeat - I see it as relevant here):
 >
 >Jed, do you have a reference to this system you could point me to?
 >
 >Thanks,
 >Neal

Regarding:

I don't believe there were any documents on that system published
external to LLNL...  I'll still look for that document in my basement.
However:

I did notice that the Datamation article that John Fletcher wrote about
the Octopus network in 1975:

http://portal.acm.org/citation.cfm?id=810357
also temporarily at:
http://www.webstart.com/papers/octopus-fletcher.pdf

had a brief mention of the Elephant storage system:

The central Octopus filing system, called Elephant,
which uses the 10**12-bit Photostore [3] , is accessed
through a system of directories [4] . A directory is
a special kind of file which associates pointers to
other files with symbolic names for those files;
the files so listed may be either simple (data or
program) files or other directories. The entire
directory structure is of the form of a general
directed graph. A user can access only that portion
of the structure accessible by a chain of
pointers starting at a root directory associated
with him. This scheme has proven a considerable
success, particularly since it provides the
opportunity for very general information sharing
arrangements among users, as well as permitting
each user to logically structure his data in a
convenient way.

[3]  J. D. Kuehler and H. R. Kerby, A photodigltal
mass storage system, Proc. AFIPS FJCC, vol.
29, November 1966, 733-742.

[4]  R. C. Daley and F. G. Neumann, A general
purpose filing system for secondary storage,
Proc. AFIPS FJCC, vol. 27, November 1965,
213-229.

(try finding those last references).  However, the
above doesn't describe the give and take mechanism.
It also doesn't describe the access permissions on
the directories.  One in particular that I find somewhat
interesting that I'll mention here is what was referred
to as the:

"inheritance" bit.

By the time of NLTSS this property became a permission
that essentially granted the authority to fetch un reduced
permissions from a directory.  That is if you had this
"free access" access permission in your directory
capability you could fetch permissions (object access)
out of the directory without modification.

If you didn't have this "free access" permission, then
permissions not in your directory capability were turned
off in the fetched capability.

This practice of course meant that the access permission
bits had to be laid out so that those for directories mapped
to those for files (and in NLTSS for other objects like
processes, accounts, etc., etc.).

I was never entirely satisfied with this mechanism, but it
did meet an important need in the Elephant/NLTSS directory
structure.  Specifically, suppose I had developed a rather
large directory structure containing directories and files of
various sorts.  I put this structure together and in it
one found read-write capabilities to various directories and
files.

As some point suppose I wish to grant you read-only
permission to this whole structure.  I can do so by
copying a capability to the root of the structure into your
take directory with the write permission and the "free access"
permissions turned off.  Then if you fetch anything out of
this directory it will also have its write bit and it's free
access bit (e.g. it might be a directory itself) turned off.

Perhaps others have encountered a similar need and maybe
come up with a better mechanism for dealing with it?  As I
mentioned I'll look for fuller documentation on the Elephant
and NLTSS directory architecture.

--Jed http://www.nersc.gov/~jed/