[cap-talk] Don't understand capabilities
naasking at higherlogics.com
Fri Oct 27 08:13:16 CDT 2006
Marcus Brinkmann wrote:
> I think that ACLs and ambient authority works closer to the real world
> than capabilities do. Say I want to set a book on fire. The ability
> to set fire on a book is part of myself, but this ability includes to
> burn any book out there, not just a couple. The question which book I
> am allowed to burn depends on which books I own. But ownership is a
> bidirectional property. We say: "Marcus owns this book." as well as
> "This book is owned by Marcus." In fact, some people write their
> names into their books so that people can identify the owner.
> Of course, this is not the whole story. If my book is locked away in
> a safe, to which I do not have a key, I can't burn it. However, I can
> still name it, and the book still "names me" as the owner. In fact, I
> can name other people's book just as well as my own. If I sell a book
> I own, ownership is transfered, but my ability to name it is kept
> intact. This is essential for example to settle disputes.
> It seems to me that in the real world, designation and authority are,
> in fact, separated.
I don't think this analogy is correct. "Naming" the book in your
scenario is "out of band" data for operating on it; ie. it's not
actually used when operating on it. So it's inconsequential to access
control. Capability systems can still provide this sort of naming; it's
You still have to be able to touch the book to actually operate on it
(open it, read it, burn it, etc.). That's a capability. Any disagreements?
As for the "naturalness" of capabilities, what could be more natural to
a programmer than an unforgeable reference? Pointer arithmetic is
learned, and with great difficulty.
More information about the cap-talk