[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)
Jonathan S. Shapiro
shap at eros-os.com
Fri Feb 8 16:54:31 EST 2008
On Fri, 2008-02-08 at 13:07 -0800, Jed Donnelley wrote:
> On 2/7/2008 7:29 AM, Jonathan S. Shapiro wrote:
> > On Wed, 2008-02-06 at 11:43 -0800, Jed Donnelley wrote:
> >> On 2/6/2008 1:03 AM, Toby Murray wrote:
> ...
> > Challenge: please try to state what *you* mean by "adding a capability"
> > and its impact on authority. Try it first using reasonably precise
> > English, and then try to formalize it. I suspect you will find that the
> > notion you are trying to capture proves to be very squirmy indeed.
>
> Whew. This seems to be becoming a seriously conflicting set of
> views. I started to wonder during the course of this message if
> this conflict might be resulting from your focus on the
> operation of the deputy (its programming) in terms of whether
> or not it can be confused vs. my focus on the environment
> of the deputy in terms on whether - even if it's coding were
> optimal - it has any possibility of clarifying just what
> authority it received from its client.
Jed:
My challenge has absolutely nothing to do with deputies. It has to do
with getting straight what we mean by authority.
> That said, let me address your challenge and see if I
> can provide any additional clarity:
>
> What I mean by "adding a capability" is simply adding
> a capability token to a c-list. Before the capability is
> added the subject is able to perform any sort of invocations
> on the other capabilities in its c-list, passing any to any
> others, but it can't invoke or pass the to be "added"
> capability.
Okay. This is about what I expected...
> The subject's "authority" is whatever is
> available through the "emergent" properties of the
> servers that it has available under those circumstances.
...but your notion of emergent authority requires substantial
refinement. Try to define precisely what difference in per-subject
authority exists before the capability is added and after, but before
you tackle that, try to define precisely what it is you mean by "the
authority of a subject". Because it is an emergent property, authority
is an intertwingled property, and getting a clear statement about what
"the authority of a subject S" even means is going to prove elusive.
> After the capability is added the subject can perform
> invocations on all it's previous capabilities as well
> as the newly added capability, including passing any
> of the original capabilities and the new one to any
> now in the list. The subject's new "authority" is whatever
> is now available through the "emergent" properties of the
> servers that it has available under these new circumstances.
This does not seem to take into account reflexivity of invocation.
> When you say, "try to formalize it", perhaps you can
> explain what you mean or give an example. The above seems
> adequately "formal" to me.
I mean try to state it formally in mathematical notation. Your
description above is not even rigorous, never mind formal.
>
> >> In the interest of simplicity can we try the modification of
> >> Toby's original (simple) statement that I suggest in:
> >>
> >> http://www.eros-os.org/pipermail/cap-talk/2008-February/009831.html
> >>
> >> Namely:
> >> __________
> >> In any case in which a service may get more authority than its client
> >> from a capability, the service is potentially confusable by that
> >> capability sent from the client.
> >> __________
> >
> > For reasons that I have already addressed -- and that Toby has agreed
> > with elsewhere -- this statement is devoid of content unless we are
> > prepared to formally analyze the program obeyed by the service. In the
> > absence of such analysis, the service is presumptively a maximal
> > conspirator, and the client and the service therefore have identical
> > authority throughout the scenario.
>
> I'm not sure where the confusion lies, but one thing I
> believe is that whether or not the opportunity for "confusion"
> exists...
Not relevant at the moment, because we cannot talk about the
consequences of confusion until we can talk accurately about authority.
Your discussion of confusion rests on an as-yet undefined term. Let us
get the term defined first.
shap
More information about the cap-talk
mailing list