Re: Split Capabilities: Making Capabilities Scale Mark S. Miller (markm@caplet.com)
Thu, 06 Jul 2000 20:32:51 -0700

This has been a wonderful thread that I'm only now caught up on. (I'm just now emerging from the black hole that Jonathan is about to enter into -- moving. We've just relocated to beautiful La Honda.)

IMO, Norm & Jonathan have represented well the conventional capability view, and the view from capability OSes, so I'll focus on the view from capability languages & libraries, especially E & ELib.

At 09:30 AM 6/27/00 , Karp, Alan wrote:
>The problem is the number of capabilities I need to deal with. After all,
>my PC has over 60,000 files on it. In the most general case, I need a
>conventional capability for each operation, e.g., read, write, execute, for
>each file. Some applications, SAP comes to mind, have hundreds or thousands
>of methods, each of which I might want to control separately. The number of
>capabilities to be managed becomes a problem quite quickly.
>
>Wildcards are often used to reduce the number of capabilities needed, but
>this approach is dangerous and not general enough. What happens if I put a
>private file in a directory that has an outstanding wildcard capability
>granting read access to general users?

We need to distinguish between 1) using capabilities in a natural capability style vs 2) using capabilities to wrap legacy non-capability-oriented systems (like file systems) vs 3) the possible advantages of proposed new styles.

  1. When designing new abstraction to be implemented in E, and implementing them, I have also found, like Norm and Jonathan, that multi-faceted objects ( http://www.erights.org/elib/capability/ode/ode-objects.html#facets ) rarely have more than three facets. A facet corresponds to Norm's "forseen" restriction of the operations available on an object. The designer on an abstraction communicates a lot to his users by designing such forseen facets. He effectively says: "These are the kinds of authority distinctions over this object that I find coherent and expect to be useful." Although the E user is easily able to make thinning frontends for unforseen restrictions as Norm describes, rarely does she do so. Usually when frontends are created that subset the original authority in some interesting way, it does so by object abstraction -- also adding new semantics. An example http://www.erights.org/elib/capability/ode/ode-bearer.html is the CoveredCallOption as an authority-reducing frontend to the original stock.
  2. Let's use file systems as the canonical legacy problem. There are two approaches to bridging these worlds. For capability OSes, the attractive option would be to rebuild a file system equivalent out of capabilities. Ie, capabilities are underneath, and the legacy is rebuilt (or virtually rebuilt) to run on top. In E the layering is the other way around. An E vat is designed to run as an unprivileged user program on top of stock operating systems, including stock file systems. The file I/O accessible to an E process must be rationalized into capability terms not by rebuilding it, but by wrapping it.

The wrapping is actually two layers -- E wraps Java's wrapping of the operating system provided services. Java provides the "platform abstraction layer" -- providing an adequately common interface to the intersection of the semantics of these OSes. E provides the capability rationalization.

E's wrapping of the file system ( 

http://www.erights.org/elang/uri-exprs.html , 
http://www.erights.org/elang/text-file-io.html , 
http://www.erights.org/javadoc/org/erights/e/meta/java/io/package-summary.html
) does not pre-create a capability for each file accessible to the E process, much less each possible separate authority over each file. To do so would be madness. Instead, it creates such capabilities on demand. A "File" object representing a directory gives access to all files and directories in that directory, recursively. (But only to those accessible to this E process under this OS, and not including "." or "..".) Only two forseen restrictions are provided: "readOnly" and "transReadOnly". For a leaf file, the two are identical. For a directory, the first is one level while the latter is transitive. Of course, the E user is free to program up all sorts of other types of restrictions, such as those based on wildcards. But as designer of the forseen restrictions, I only felt that these two deserved to be included.

(Note the difficulty of formally distinguishing between an authority-restriction facet and anything else. For example, if directory A contains directory B, then B can be obtained from A and grants less authority than A. Would we say that B is a restriction of A's authority?)

3) This is where I hope split capabilities may make a real contribution. The examples you've been using for the scaling problems of capabilities aren't grabbing us, because capabilities used in the style we're using don't have these problems. Perhaps what has happened is that, precisely because of the problems you are concerned about, we have evolved a style that's co-adapted to these problems, and have missed opportunities that lie outside our style. I don't know, but it seems a fruitful direction to explore.

More later.. 

         Cheers,
         --MarkM