[cap-talk] cap-share - membranes - optional/mandatory, unwrapping? (was: Blue sky)

[Marcus Brinkmann]

At Sat, 16 Dec 2006 23:00:00 -0500,
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> Get serious! We are talking about fine-grain, capability-connected
> object structures here. Even if there was a tool to audit the structures
> and offer to replace the capabilities sensibly (a tool we probably
> should NOT build, for reasons given below), Alice has absolutely no clue
> what any of these pointers mean, what they connect, or where she got
> them from (Bob's delegations may go back for years). Losing the
> structures isn't an option -- the data structures contain critical state
> that commingles capabilities and data from ALL of the members of the
> group.
> 
> Under these circumstances, the *only* sensible thing for Alice to do in
> the real world is to say "yes, exchange all of my Bob Capabilities from
> Carol for direct capabilities from Carol" or "no, don't exchange any of
> them and I'll clean up the mess by deleting all of the broken and now
> unrecoverable objects". From a technical standpoint neither is the right
> thing to do, but from a real-world standpoint these are the only
> realistic choices.
> 
> No. The way to think about this case is to say that Manager/Carol (the
> group manager role, whose current occupant is Carol) has delegated these
> authorities to the group as a whole, and it happens to be Bob who was
> the proximate recipient. Bob's later transfer of capabilities to Alice
> is a transfer, not a delegation. It is a transfer because the capability
> did not cross a revocation domain. What needs to happen here is that the
> Bob-membrane/Alice-membrane pair need to notice that this capability is
> crossing a capability exchange boundary, and transparently implement the
> capability exchange. In the limit this type of capability exchange needs
> to selectively untangle the causal dependency tracking.
> 
> Notice that in the end what really happened here is not that we revoked
> Bob's authority, but rather that we disassociated Bob (the user) from
> "Bob, the employee acting in their role as a member of Carol's group".
> That is, Bob's capabilities here aren't really contingent on their
> source. They are contingent on Bob's continued association with his
> current role.

This is of course an important design pattern.  I am not sure where
the difficulty in this conversation lies.  It may be that whenever one
important design pattern is discussed, everybody focusses on that and
tries to apply it to every problem.  That would be non-sense.  There
are important uses for revocable delegation, and there are important
uses for "transfering" capabilities to group members.

But note that what actually happens in the group example is not
necessarily a transfer.  What happens instead is that the group, as
its own principal, dominates all members of the group.  In real life
there will possibly be a group leader who in turn dominates the group,
unless the group is part of the system architecture.

If layed out in this fashion, I don't see a contradiction: If you get
it right, revocable delegation can be used to manage group
capabilities.  However, *exchange* of group capabilities would then
never happen directly.  Rather, everybody would get their capabilities
delegated from the group.  This raises different questions, for
example how to name such group-accessible objects in communication
between group members.  But I don't think that this has anything to do
with revocable delegation.

Note that you can't use capability copy to communicate group
capabilities either: From where should the assurance come that a
received capability is in fact a group capability and not a proxy or
some foreign object?
 
> This seems to suggest that the decision procedure for membrane crossing
> is much more complicated than we want to believe, and may have more to
> do with organizational roles than with causal relationships. At best, it
> means that cross-membrane interactions are more complicated than we have
> wanted to acknowledge.

It seems to me rather that this is a matter of not everything is a
nail, even if you have a cool looking hammer.
 
> Concerning the audit tool, there are two problems:

[...]
 
>   2. The audit tool requires a "God's eye" view. It requires the
>      authority to walk every object in the system and implement the
>      exchange protocol. The minute we introduce such a walker, we
>      have re-introduced something very close to universal (root)
>      authority, and that ought to make us very skeptical about the
>      design under discussion.

Most people here seem to say that god's eye is not necessary.  I want
to point out a slightly different tack, which you probably won't like,
but is a matter of reality catching up on us.  Email retention has a
long history of being relevant in law suits[1] and now the fire is
rapidly spreading to instant messaging.  The nail in the coffin could
be the Mark Foley sex scandal.

You may have all sorts of reasons to separate access to digital
objects in your organization, but when the judge brings the hammer
down God's eye is on you, and you better be able to produce, or face
heavy fines.

Thanks,
Marcus

http://www.baselinemag.com/article2/0,1540,1998003,00.asp