[cap-talk] ... enforcement - ambient authority - definition?

[David Wagner]

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?

Yes, exactly.

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.