[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

On 12/08/2007, at 22.21, David Hopwood wrote:

>Valerio Bellizzomi wrote:
>> On 11/08/2007, at 19.03, Jed Donnelley wrote:
>> 
>>> As we well know, the "pass once" mechanism for
>>> 'raw' capabilities makes no sense.  It blocks the
>>> development of finer grained implementations
>>> of services (introducing more objects) because
>>> the holder of the capability can't even communicate
>>> it to new "sub" objects.
>
>Yes. Note that 'do-not-delegate' only represents an enforceable
>constraint when the subject that holds the capability is (at least
>partially) confined. In that case, it cannot delegate to a subject
>outside the confinement boundary without going through a component
>that is able to enforce use of some delegation tracking protocol.
>In all other cases, use of delegation tracking is strictly optional.
>
>It seems increasingly clear that, in order to address many of the
>most common perceived problems with capabilities, principals are
>going to have to be separated by membranes. I personally think this
>is an unfortunate complication -- I think that a system without
>membranes would work perfectly well in practice, or at least much
>better than existing non-capability systems. Hopefully, we can
>reduce the overhead of membranes to a reasonable level (I'm thinking
>mainly of conceptual overhead and implementation complexity, rather
>than performance overhead; the latter is unlikely to be significant
>even for a fairly naive implementation).
>
>> If it is possible to do this with a counter inside a capability, it
would
>> become 'delegate N times'.
>
>I don't see why a counter greater than one would be useful here.

The counter could represent the number of sub-object layers within an
application, or it could simply represent the number of re-delegations,
starting from the originating object, and tracking delegation chain. If N
is determined by a call graph, it is indeed determined statically at
compile time. If N is computed at application boundary, it could very well
be variable. 



>
>-- 
>David Hopwood <david.hopwood at industrial-designers.co.uk>
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk