On Mon, 2006-05-01 at 04:44 +0200, Marcus Brinkmann wrote: > > In case (B), I believe that this sort of "opaquely held" capability > > should count as a capability that the instantiating process does not > > have -- though I am not certain of this. There are handshake protocols > > here that could probably prevent DRM without going as far as you > > suggest, and I would like to explore these alternatives more carefully. > > > > But for the moment, can you also clarify how the capabilities of case B > > fit into your definition? > > They also count as capabilities that the instantiating process does > not have, if they are only opaquely held by the instantiator. > However: If they allow communication outward, then that means they > violate rule (3), because some behaviour by the instantiated process > (namely, an invocation of such a capability), can be observed by a > process not directly (or indirectly, in the way I explained) > authorized by the instantiator.
By providing the bag to the constructor, the instantiator is authorizing the use of any capability in the bag, subject to the additional requirement that the capability is also stored within the constructor. This is very definitely an authorized capability in the sense of your rule 3 -- in effect, what is happening is that the instantiator is delegating a subset of its authorization decisions to whoever fabricated the bag. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
