[cap-talk] On revocation and the use of wrappers

[Kevin Reid]

On Dec 5, 2006, at 9:38, Neal H. Walfield wrote:

> Let's say that I have the following scenario: Frank is a file object
> to which Alice has read and write access.  Alice wants to give this
> object to Bob but wants to reserve the right to revoke this access
> later.  Let's say she uses a wrapper so Bob has access to Frank'.
> Now, Bob decides to delegate some of his access to Carol.  Namely, he
> wants to only delegate read access to Frank' to Carol.  Jonathan has
> advocated that the access bits should not lie in the capability but in
> the object.  As such, this delegation requires an interaction with the
> server.  Bob invokes Frank' with the fetchReadonly method and receives
> in his reply FrankR.  FrankR will continue to provide access to the
> file object even after Alice revokes the Frank' wrapper as Alice
> didn't use a membrane.  Here is the resulting access graph:
>
>                      Frank <--- FrankR
>                      ^   ^         ^
>                     /     \        |
>                  Alice -> Frank'  Carol
>                            ^
>                            |
>                           Bob
>
> What's the right solution here?  Should Alice have used a membrane?
> Should membranes be a first class object (like wrappers in EROS).  If
> so, how should resource accounting be done?

As an E programmer, I would say that the /error/ in this scenario is  
that Frank' should not have simply forwarded the fetchReadonly message.

Instead, Frank' can generate a new sibling wrapper, which could be  
via a membrane or by protocol-specific wrapper objects, or ask Frank  
or FrankR to provide a revocable capability.

> This seems to me to be in conflict with the notation that I, for lack
> of better name, call "access refinement without interposition," which
> I think may be a cornerstone to building efficient systems on a
> capability framework.  This pattern is realized by EROS and KeyKOS by
> space banks: ...

It seems to me to be fundamental that without-interposition can be  
done if and only if the server supports the refinement pattern  
desired. EROS space banks do this for revocable subdivision.

Might it be possible to write reusable libraries for providing such  
server-side-refinement interfaces?

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>