[cap-talk] Definition of "authority"? Got it right?

[Jed Donnelley]

On 1/22/2008 9:34 AM, Kevin Reid wrote:
> On Jan 22, 2008, at 10:44, Mark Miller wrote:
>> On Jan 21, 2008 10:21 PM, Jed Donnelley <capability at webstart.com>  
>> wrote:
>>>  What bothers me about this definition set is that, at least for  
>>> object capability systems, it seems to somewhat trivialize the  
>>> notion of a "permission".  Permissions are always the same.  They  
>>> only provide communication.

>> In all ocap systems of which I'm aware, both language and OS, the  
>> kernel does provide some object types primitively -- such as an  
>> indexable read/write data container of some sort. E provides  
>> FlexLists. The KeyKOS line provides segments and nodes.
> 
> This doesn't seem to fit to me.
> 
> In E, a FlexList (whether or not it is implemented primitively [1]),  
> or any other possibly primitive object, is *used* via the same  
> operation, the call ("communicate"), as every other object; at the  
> level at which these would be considered different permissions, it  
> would be equally reasonable to consider various types of user-defined  
> objects different permissions.

I think the above is exactly the point I was making
(perhaps less succinctly) when I said:

Jed said:
<in: http://www.eros-os.org/pipermail/cap-talk/2008-January/009615.html >
> Isn't it also true (or perhaps shouldn't I say, 'shouldn't
> it also be true?') that even if the TCB does provide something
> other than the "invoke" mechanism (and of course the extension
> mechanism to enable it), then at least from the perspective
> of a user process it should appear that "invoke" is all that
> is provided by the TCB?  That is, any capability should be
> able to be emulated by the extension mechanism.  If that is
> the case, then it should appear from the API that all
> capabilities provide only the "invoke" facility.

- and thus that all capabilities at least appear from
the perspective of the API to "permit" only the direct
communication to the service object.

To me this suggests, especially for object capability
systems, that the "permission" notion as used in MarkM's
thesis and seemingly on cap-talk has rather limited
utility.  It seems most important for distinguishing
TCB supported services (?).  Even then, however, one has
the rather odd notion that one is exercising a permission
when invoking a FlexList but one is exercising an
authority when invoking, say, a Horton object.  The
definition is thus rather implementation dependent and
not so much tied into the interface.  Another example
might be that when we optimized the NLTSS system by
pushing the file server into the kernel of the
system (without changing the interface), we changed
file capabilities from "authorities" into "permissions".

There is one other minor English aspect that bothers me
a bit about the "authority" term.  There is no singular
form of "authority".  If we were to use the term
"permission" to refer to the authority that a single
capability provides, then we could distinguish that
one "permission" (which could in fact be a rather
complex 'authority') from the sum of the "permissions"
available to the subject by virtue of its set of
capabilities.  In fact, it would seem to me reasonable
to refer to this sum of permissions as the subject's
"authority" - with perhaps throwing in any other
'authority' that is less directly derived (though
perhaps not all the way to "ability" as MarkM uses
it to include covert channels).

With the term "authority" one can't use the singular
and plural forms to distinguish between that which
is provided by one capability from the whole
authority available to a subject.

Still, just words.  I'm happy to finally understand the
concept that has befuddled me for some time.  I'm somewhat
mollified to understand how my background uniquely qualified
me to misunderstand ;-)

--Jed  http://www.webstart.com/jed/