RE: Split Capabilities: Making Capabilities Scale Karp, Alan (alan_karp@hp.com)
Fri, 7 Jul 2000 17:52:29 -0700

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