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

[Jonathan S. Shapiro]

On Wed, 2006-12-06 at 19:13 +0100, Neal H. Walfield wrote:
> At Tue, 05 Dec 2006 10:11:24 -0500,
> Jonathan S. Shapiro wrote:
> > In practice, however, the problem doesn't seem to work out in the way
> > you describe, because the case of "object capability points to server"
> > is almost never observed in the wild. The problem with this design
> > pattern is that it prevents the server from performing selective
> > revocation of objects. The practical consequence is that servers tend to
> > issue wrapper capabilities that encapsulate server capabilities rather
> > than the server capabilities themselves.
> 
> As I understand you here, your claim is that it is almost always the
> case that the server hands out wrapped capabilities, correct?  From
> our discussions, I seem to remember that selected revocation is
> actually a rarely useful pattern--and it's in this vein that I've been
> thinking about designing servers.  Could you more fully motivate this?

I can try. :-)

There are two distinct cases, because in practice there are two types of
servers:

  Servers that implement exactly one object. The current EROS directory
    server is an example (though this may be a mistake). For such
    servers, the destroy operation naturally kills the whole server, and
    there is no need to wrap things.

  Servers that implement multiple objects. In this case you probably
    want to be able to destroy the objects individually, so you hand
    out wrappers on a "one wrapper per object" basis.

> Say Alice has a capability to Bob and she wants to delegate revocable
> (perhaps, but no necessarily, weakened) access to Carol.  As I
> understand you, she would call the appropriate fetch method and pass a
> sub-space bank to Bob with enough space for him to allocate a wrapper.
> Correct?

Depending on the storage discipline involved, the object server might
use its own bank, but yes, this is the basic pattern.

> > While the original provider can shoot the bank, this doesn't guarantee
> > revocation, because the client can make a new wrapper for itself using
> > its own storage and discard the original; the server cannot tell.
> 
> What I think you are saying, staying with the above example, is that
> Carol could invoke the fetch method and get her own wrapper (which is
> inferior to the one she got from Alice).  Then when Alice shoots the
> space bank, her access would be cut off but her wrapper would not be
> deallocated.  Is that correct?

Yes, this is the problem scenario. Context here is that I'm gearing up
to try to state the problem clearly so that I can set out a "propose a
viable design pattern" challenge.

> > In any of these cases, I still claim that the revocation pattern is
> > rare.
> 
> Then why always wrap server capabilities?

Because the servers serve multiple objects. In my sentence above, I
meant to write that "revocable delegation" is rare. This is true both
because there usually will exist multiple processes within a single
delegation domain, and also because most objects are never delegated.

> > My argument is that well-structured applications have failure
> > domains that are smaller than their revocation domains.
> 
> Could you please elaborate this claim a bit.  I feel that there is
> some important, fundamental point here but I'm unable to get at it.

I think what I am saying is that (a) all membrane boundaries (i.e.
places where you would want to insert a membrane) are domain boundaries,
but (b) only a subset of domain boundaries are membrane boundaries.

Two examples:

  1. For purposes of revocable delegation, an application implemented by
     multiple objects does not need to introduce membranes within its
     internal boundaries.

  2. A very common pattern is to create a private object (i.e. it has
     only one caller) that is destroyed when no longer needed. If the
     object as a whole is going to be destroyed, there is no need for
     a membrane. Our experience with EROS suggests that this class of
     "exclusive private objects" accounts for the majority of objects.

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100