[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Wed, 25 Oct 2006 13:49:23 -0700,
Charles Landau <clandau at macslab.com> wrote:
> 
> At 10:36 PM +0200 10/25/06, Marcus Brinkmann wrote:
> >Should the eq? operation yield true when comparing a wrapper and the
> >wrapped object?
> 
> Definitely not.

I just remember that in Coyotos (and EROS?), wrapper objects are used
by a server to discriminate between different objects, by means of the
protected payload which serves as a local object identifier.  In that
case I agree with you.

However, L4 provides other mechanisms to identify which communication
endpoint has been invoked.
 
> >If wrapping is understood to be used for revocable delegation, I think
> >that "yes" would be a reasonable answer to that question.  However,
> >one can also make a reasonable argument against is.  But then the
> >delegation is not transparent anymore.
> 
> Revocable delegation is never transparent. After revocation, the 
> revoked capability is unusable, and the original capability is not. 
> They are clearly different.

Right, I shouldn't have used the word "transparent".

However, your assumption is that something like a distinguished
"original capability" exists.  If revocable delegation is the only
primitive delegation mechanism, programs may not expect capabilities
to be durable resources, and thus may not care about the distinction.

> >Personally, for the use cases I think about most, I think that
> >revocable delegation should be transparent to eq?.
> 
> Can you give an example? I'm sure that example can be served by using 
> some other mechanism, perhaps the Alleged Key Type, rather than eq?.

I am working with the (strong) assumption that revocable capability
delegation is the only primitive capability delegation mechanism in
the system.

Let's look at a capability invocation that passes capabilities as
arguments.  This may be rights amplification, or a simple case of an
operation that works on more than one server object at the same time.
A simple example of the latter is an operation that does a virtual
move or copy from one resource container to another.  Another example
is a file rename operation in filesystem servers that do not support
multiple links (for example FAT).  Another example is a server
providing user ID authentification based on the Hurd's auth protocol
or a variation of it.  All these examples have in common that there is
an operation:

error_t foo (obj_t obj1, obj_t obj2, ...);

where both objects, obj1 and obj2, are implemented by the same server.

(I believe in EROS this issue is addressed with a "branding"
mechanism.)

This is how the mapping database looks before the invocation:

   S e r v e r
   |obj1   |obj2
   v       v
   C l i e n t

This is how the mapping database looks after the invocation:

   -- S e r v e r --
   |obj1   |obj2  ^
   v       v      |obj2
   -- C l i e n t --

The server now must perform an eq? operation on its own mapping of
"obj2", which is at the root of the mapping tree, and the mapping of
"obj2" which it got from the client, which is a leaf node of the
mapping tree.

The server can not rely on an alleged object ID provided by the
client, obviously.

The important feature is that for the purposes of authenticating the
operation FOO on obj1 and obj2, the server is satisfied to receive a
revocable copy of obj2.  There is no need for obj2 to be a copy of the
"original capability".

I have studied to some extent system design solutions to common
problems where the lack of durability of revocable copies is not
problematic.  This can be achieved through careful construction of the
process dependencies.  To somebody used to capability copy, this seems
restricting.  However, it does not really appear to make a dramatic
difference in practice.  I am not sure I have covered all possible use
cases yet, though, and my priorities may be different from common
capability-based systems.

Thanks,
Marcus