[cap-talk] OCap directory discussion (was: Waterken Server (was: A paper on web-keys))

[Jed Donnelley]

At 08:47 PM 1/24/2008, Bill Frantz wrote:
>tyler.close at gmail.com (Tyler Close) on Sunday, January 20, 2008 wrote:
>
> >I think a common theme across many design patterns for handling
> >upgrade will be to dodge the problem as much as possible. For example,
> >one approach is to design a set of classes whose sole purpose is to
> >hold your long-lived state. These objects are kept as simple and
> >generic as possible.
>
>Traditionally these objects are files and directories.  Thus you
>have described the approach used by Unix, MacOS, Windows etc.

I agree.  However, I think it's important to note that an
OCap directory is a very different animal than the Unix, MacOS,
and Windows (UMW?) directory.  The UMW directories are used
for naming and storing access rights (e.g. RWXs..).

An OCap directory (at least as I understand it, the reason
I'm writing) also performs the naming role and does store
access rights in a sense, but it is in a very different
sense.

The way OCap directories (that I'm familiar with) work is
essentially as c-lists work in Dennis and VanHorn, except
with names instead of indices.  That is, if I have a
capability to a directory, then I can fetch (with possible
restrictions) any of the capabilities stored in the
directory, by name.  Once I've fetched a capability
(e.g. another directory), then I can invoke that fetched
object any way that others with the same object can,
creating a natural directed graph directory structure.

Add a Horton mechanism so that you can inject a more
flexible PDP with identity based access control through
explicit delegation, and you have what seems to me
quite a flexible and powerful access control scheme
that can be conveniently used across organizations
(e.g. across the network) - even with enforced
policy mechanisms like MLS or other sensitive
information controls.

However, part of the reason I mention the above is
that such a mechanism is counter intuitive to most
computer users today, and may be a difficult "sell."
I didn't really understand how much of an issue this
might be until I discussed the above with David
Wagner in a conversation at Usenix.  As I recall
that discussion, David suggested that people might
find the thought of sharing through what amount
to bags of named capabilities uncomfortable.
Perhaps this goes back to the old "loose
capability" concern?  Is there more to such
discomfort?

For me such OCap directory sharing is so intuitive
from many years of experience with it (except for
the Horton part) that it's actually more intuitive
than the UWM approach, where directories to me seem
sadly lacking.  With Horton identities including a
flexible Policy Decision Point, it seems to me that
there is a more flexible facility through such an
approach with auditing and some amount of after the
fact control.

Still, I wonder if there is a common "view" of
what OCap directories consist of and how they
can/should be used?  For files I believe the
situation is rather straight forward, but for
directories I guess that people may be considering
more than one set of semantics?

Just to be clear about my view, from my
perspective a "directory" is an object that
stores other object references (capabilities)
by name.  Operations on directories include
fetch (or 'read') to extract a capability by
name, insert (or 'write') to store a capability
by name, and list (to list the names of the
capabilities in the directory).  Of course there
are many variants and optimizations (e.g. the
whole discussion about "deep read only" previously
on this list), but for me the above is the essence.

With the above one can create a directory
(served by any server, anywhere), and use
it to build up a sharing structure - much
like a group.  I can create a directory
that I might think of as sort of a project
directory.  I can put some objects into
it (e.g. some file capabilities, perhaps
even some other directories - carefully),
and then delegate the capability to the
"project" directory to colleagues working
on the project.  Except for policies enforced
with something like Horton, the people
or programs that I delegate the directory
capability to can use it like I can (unless
of course I give them reduced access
capabilities - e.g. fetch-only, possibly
deep read-only, maybe even insert only...).
This creates a general directed graph
directory sharing structure.

I wanted to express these directory ideas
to get some feedback and to see where others
come down on the issue of OCap directory
semantics.

(Sorry to bury this so deeply in this
message, but) I just noticed in some recent
re reading that Butler Lampson seems to have
understood the above model of sharing
access through directories quite well.  In:

http://research.microsoft.com/lampson/06-DynamicProtect/06-DynamicProtect.pdf

, which was written while Butler was at BCC
in 1969, I believe Butler describes directories
as above and a scheme that at LLNL we referred
to as "give and take directories" (described
elsewhere) in his figure 7 in the above paper
where he talks about "sharing capabilities without
access keys".  From my perspective it's a little
muddled (only describing the "give" mechanism,
for example), but I think it's the same basic idea.

I'm going to ask around a bit to see if I can
find out if there was idea sharing going on
or if the above was an independent discovery.
At LLNL the "give and take" directory mechanism
was in place when I arrived in 1972.  I've never
taken time to figure out when it was first
implemented and where the initial concepts
came from, though I heard that some of the
early ideas came from Multics (which of
course ended up going in a very different
direction).

--Jed  http://www.webstart.com/jed-signature.html