[cap-talk] Capabilities giving up control?
John McCabe-Dansted
gmatht at gmail.com
Sun Jan 20 08:02:25 EST 2008
On Jan 19, 2008 6:28 PM, Jed Donnelley <capability at webstart.com> wrote:
> At 08:51 AM 1/18/2008, David Hopwood wrote:
> >Jed Donnelley wrote:
> >[...]
> > > I really think the sense in which we have been using
> > > "authority" on this list (sorry MarkM) is an entirely
> > > different concept. Namely the closure of what sort
> > > of access can be obtained by using all available
> > > permissions. Sadly, I don't think this fits very
> > > well with the human social notion of "authorize",
> > > e.g. (from:
> > > http://www.thefreedictionary.com/authorize ):
> >
> >Please let's not redefine terms in mid-argument. MarkM's choice
> >of "authority" to mean the transitive closure of available
> >permissions will do fine for the time being; it's concise, useful,
> >and no less well-chosen than many other technical terms.
>
> That's fine. I wasn't really trying to redefine it. I
> was just pointing out that this usage is in conflict with
> typical human social usage as in the way people refer to
> a driver's license as 'authorizing' driving on the roads
> or a passport as authorizing entry into a country. I
> think this results in some of the confusion that has come
> up during this discussion.
"Authority" seems to be very close to the common English meanings of
Influence, Power and Ability.
See e.g. http://en.wikipedia.org/wiki/Influence
However I'd like to clarify one possible exception. We may casually say that
X can "influence" Y via a covert channel, but Y might not be in the
transitive closure of permissions. Or would we say that X and Y have
permissions to the shared resource used to implement the covert channel?
However, we might still have the case: X -> Resource <- Y
But not: X -> Resource -> Y
Or are permissions reflexive?
--
John C. McCabe-Dansted
PhD Student
University of Western Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080120/2323500a/attachment.html
More information about the cap-talk
mailing list