At 07:00 PM 10/11/99 , shapj@us.ibm.com wrote:
>My apologies for getting into this thread so late. The SOSP deadline has been
>driving me very hard.
>
>I have two thoughts to add. Perhaps they may not be helpful.
>
>First, after a while working on formal stuff around capabilities, I have come to
>the feeling that describing capabilities as a
>
> (name, access rights)
>
>or
>
> (name, operation)
>
>pair is not the best description. I have not yet found good words to describe
>what I want, but here is a description.
>
>A capability is a pair of the form
>
> (name to thing of type X, some thinning of the signature of type X)
Sorry, I don't like this either, as it doesn't correspond to capabilities as
found in any of
KeyKOS, EROS,
Trusty Scheme (unpublished), Rees' very similar independent W7/Scheme48
security kernel
ftp://publications.ai.mit.edu/ai-publications/1500-1999/AIM-1564.ps.Z,
Actors, Joule, or E.
In all of these, I claim a capability best described as a combination of state and behavior (as described in the recent paper http://www.erights.org/elib/capability/ode/ authored by Chip, Bill, and myself, especially the chapters "From Functions to Objects" and "From Objects to Capabilities"). A capability does not give direct access to the state, but does allow one to invoke one of the behaviors packaged with this state. This behavior, when executing, does have access to this state.
The following remarks apply to both KeyKOS and EROS, but I'll use KeyKOS terminology as I'm more familiar with that. My apologies to the list members for whom the reverse is true, perhaps someone could translate.
A start key both designates a domain and contains a "data byte" ("tag" in the terminology our above paper). When one invokes over this capability, the recipient domain receives both the message and the tag. It will then typically dispatch to one of its possible behaviors based both on the tag and on the "order code" -- the number that corresponds to an O-O message name. The tag is therefore a narrowing of the behaviors accessible via this capability, but not necessarily a narrowing of its type signature.
Putting this in Scheme terms, the untyped lambda calculus enhanced with local side effects already is a capability system, and lambda is already a sufficient capability construction operator, without further work. Here is a scheme example of two different capabilities with the same type signature providing different behaviors over the same state:
(define (sillyPair x y)
(cons (lambda () (+ x y)) (lambda () (* x y))))
This returns a cons of two functions defined in the same scope and therefore
encapsulating the same state. They both have same type signature: no
arguments -> number. However, they each pair a different behavior to be
executed over this state.
Capabilities narrow (or select, or designate) behaviors. They don't narrow types.
Cheers,
--MarkM