Re: cap exchange race with map/unmap

[Jonathan S. Shapiro]

On Tue, 2005-10-18 at 18:24 +0100, Neal H. Walfield wrote:
> > > The requirement is that capabilities which can be exchanged must be
> > > registered with a mutually trusted capability server.
> > 
> > I don't think that this is right. The capability server must have
> > sufficient authority to obtain a capability that will not be invalidated
> > when the process that instantiated the object exits.
> 
> I am confused by "when the process that instantiated the object
> exits".  The object instantiator is the client that made the RPC to
> the server to bring the initial capability into existence, right?

Let me start over.

Our goal is to use REVOCABLE COPY to implement COPY. I assume that
REVOCABLE COPY is the only primitive capability transfer operation.
Simulation of COPY does not work unless the CapServer CS has the ability
to fabricate capabilities. Here is the problem:

A goes to some server and requests a capability Cap.

A now wishes to (logical) COPY to B.

As a first step, A performs a REVOCABLE COPY to CapServer (because
REVOCABLE COPY is the primitive operation).

A now performs a REVOCABLE COPY of the Cap to B. Assume that B correctly
executes the capability exchange protocol with CapServer.

In the absence of any authority to fabricate new capabilities, the
following chain of mappings is now in effect after the exchange:

      RevCopy                RevCopy
   A ----------> CapServer -----------> B

If process A now exits, all of its capabilities are revoked. In
consequence the Cap held by CapServer is revoked. In consequence the Cap
held by B is revoked.

Can somebody explain what authority or feature in the system design
gives the CapServer sufficient power that it can create a capability
that does not depend on A's continued existence?

I believe that the only possible protocol that could be correct is for
all object servers to return by way of CapServer. In practice, this
makes locally trusted CapServers impossible, because a general-purpose
server cannot make assumptions about how the objects it creates will
later be transferred.


shap