[cap-talk] ... enforcement - ambient authority -
daw at cs.berkeley.edu
Wed Oct 6 18:53:36 EDT 2004
Jed Donnelley writes:
>At 04:03 PM 9/29/2004, David Wagner wrote:
>Take the example (common and
>to the point I would think) of a file open call. Naturally the program must
>state what resource it's trying to open - namely the file whose name it
>specifies. Are you distinguishing between the name and the right?
In a capability list system, one might instead specify an index, which
might serve double-duty as both the name and as a reference to the right
(i.e., it indicates which of the rights available to the program is being
exercised for this particular syscall). That would avoid the pitfalls
of ambient authority.
>I guess I was keying in on the inheritance of "ambient" authority -
>e.g. in a fork or exec call.
I think inheritance is probably orthogonal to "ambient" authority.
Just as you say, even in a capability system (a non-ambient authority
system) one could inherit capabilities across a fork() -- for instance,
think of file descriptors, which are essentially a capability that is
inherited across fork().
At least, that's my understanding. I learned this terminology and
these concepts from other folks on this list, so I hope they'll chime
in if I'm butchering the idea.
>OK, I can accept that terminology, though as can be seen from the
>above and elsewhere it wasn't entirely intuitive to me.
It wasn't to me, either, if that is any comfort...
>In the classical capability list system I guess one can say
>that even if the index is a name for the resource, it is simultaneously
>a name for the right to the resource (the great value of capability systems,
>binding the name for a resource with a right to access the resource).
That's precisely my understanding.
More information about the cap-talk