Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

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