Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Thursday, July 06, 2000 8:33 PM
> To: Karp, Alan
> Cc: 'e-lang@eros-os.org'
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 			(snip)
> 
> 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.

I don't see the usefulness of the distinction.

> 
> 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.

As I said in my earlier note, it wouldn't surprise me if the effective
number was 3 capabilities per object.  However, I have seen objects with
many more separately controllable methods.  The real point is the scaling
law.  Yes, finding ways to reduce N or M will delay the point where you need
to worry about your scaling being N*M.  That's the whole point about having
group permissions for Unix files.  Such solutions often introduce problems
of their own.  We need to remember that N+M scaling is always better as long
as you don't lose anything to get it.

(Outlook lost the > at the start of the forwarded lines at this point.  From
here on out, I'll enclose my comments in --------.)

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-speak does the same thing.  Our VFS contributed application is a user
process running on top of the Java system abstraction accessing files as
would any other process.  E-speak provides the naming, virtualization,
management, and security pieces that it provides for any e-speak resource.
--------------------

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.ht
ml
) 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.

--------------------
Lazy creation is a good idea, but if you're talking about objects with a
long lifetime, such as files, you'll eventually end up creating all or
almost all of the capabilities.  Therein lies madness if you have N*M
scaling.  

I don't like the idea of giving transitive permissions, such as all
contained directories and files.  That means I must understand the
permissions granted to each entry in the path to the file before I put it in
some directory.
--------------------

(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.

--------------------
Sometimes we get so used to dealing with problems that we forget they're
problems at all.  I've got stories to tell on this one.
--------------------

More later..


         Cheers,
         --MarkM


_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278