[cap-talk] capability copy and capability map

[Charles Landau]

At 10:17 PM +0200 10/24/06, Neal H. Walfield wrote:
>At Tue, 24 Oct 2006 12:58:19 -0700,
>Charles Landau wrote:
>>
>>  At 7:46 PM +0200 10/24/06, Neal H. Walfield wrote:
>>  >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
>>
>>  In L4, what happens if A ceases to exist and B continues to exist?
>
>All capabilities which A mapped are implicitly unmapped.

Then how can L4 support things like the installer pattern? On my 
desktop computer (which happens to run MacOS), when I install new 
software, an installer program runs which sets up the new application 
with the files (read capabilities) that it needs. The installer is 
then no longer needed and quits. It would seem that in L4 the 
application would then lose all the capabilities the installer had 
given it.

At 7:46 PM +0200 10/24/06, Neal H. Walfield wrote:
>this pattern may not actually be useful.

I'm not sure which pattern you are referring to.

EROS/CapROS/etc permits capability copy (by default), and also allows 
you to explicitly choose L4-style revocation (by, for example, 
granting a wrapper object built from your own space bank). Thus you 
have the choice of either pattern. L4 appears to force one pattern, 
since I don't know how to support capability copy on L4.