[cap-talk] capability copy and capability map

[Neal H. Walfield]

At Tue, 24 Oct 2006 13:30:29 -0700,
Charles Landau wrote:
> 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.

I think this is a question of when linking should occur.

In the constructor pattern, linking occurs at installation time: the
program is given access to a number of resources by the installer
based on the installers authority.

When linking occurs when the program is executed--when all of the
program instance's authority is derived from its parent--then the only
responsibility of the installer is to copy data into the right places.
In this case, the installer requires some access to the file system
which is granted by the installer's shell.

To facilitate de-installation, I think that the right approach may be
to have the installer allocate all files out of a sub-space bank.

> 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.

Right.  May question is: what is a useful scenario which can be solved
with capability copy but not with map?

Thanks,
Neal