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

[Neal H. Walfield]

I have understood from my interactions with the capability community
that the need for revocation is the exception and not the rule.  This
is one reason to not use a wrapper by default, as is done in, for
instance, the L4 world.

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?

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: the revocation chain is deep and preserved by the server
which maintains a hierarchy, however, the invocation chain is short:
when you invoke a space bank, it typically results in a direct message
sent to the space bank server.  It is also typical of memory: there
are access bits stored in the capability which can be used to refine
the access to the object without requiring interposition to restrict
write access.