[cap-talk] capability copy and capability map

Neal H. Walfield neal at walfield.org
Tue Oct 24 12:46:47 CDT 2006


This inquiry is based on a conversation I had yesterday with Marcus.

Capability copy appears to be the preferred behavior for capability
propagation--at least, I think, by capability practitioners on this
list.  Redell's caretaker is then built on top of this.

The L4 community does not have capability copy: capabilities are
always revocable by the process which did the delegation.  Thus, if A
has a capability designating S and wants to pass it to B, the
resulting access graph would look like this when using capability
copy:

     .-- A
   S<
     `-- B

whereas it looks like this when using map:

   S -> A -> B


I think the choice by this community is an interesting one as the
pattern for resource delegation is based on revocation.  On Eros, for
instance, creating a process involves creating a new sub-space bank,
allocating the process out of it and providing the sub-space bank to
the new process.  In this way, the parent is able, at any time, to
destroy the child and any objects it allocated.

If the parent is able to destroy any objects that the child allocate,
then any capabilies which designate those objects will essentially be
revoked when the child's space bank is destroyed.  This includes, for
example, any pixmaps the child allocates on a graphics server which on
Eros, as I understand it, would normally be allocated out of a a
sub-space bank provided to the server by the child process.

Capability copy is useful if we want delegations that the child
performed to persist after the child is destroyed.  That is, in the
above figure, B's access to S is limited to the lifetime of A when
capability map is used.  The most convincing use case I can come up
with at the moment is that a process installs a capability into a slot
in a directory server.  The process must necessarily not implement the
object or own it (like the bitmap above) or it will be revoked when
the process is destroyed.  So, it must be some other object.  A
program which follows this pattern is ln.

But is this what we want?  Having spoken with Jonathan about how to
recover the results of a delegated computation, we normally want to
serialize the results and copy them somewhere.  Generalizing, the only
program I actually want to manipulate the capabilities which compose
my home directory is my shell or powerbox.  Thus, this pattern may not
actually be useful.


I'm interested in other's take on this issue.

Thanks,
Neal


More information about the cap-talk mailing list