alt Hacker NewsIf you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
OP is arguably the first paper that introduces ocaps. Some of the issues are discussed in "Capability Myths Demolished" https://papers.agoric.com/assets/pdf/papers/capability-myths...
Replies
I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible.
They mention a compiler having access to a file called BILL for storing billing information and if you specify that it is the file for debugging then it is overwritten by the debugging information. While an appropriate kind of capability system (such as proxy capabilities, or object-capabilities described in that article which is very similar) can help, locking the file might also help (if it is locked for billing first before any files specified by the user are locked); then the compiler will complain that the file specified as the debugging output file cannot be written because it is locked (even though the compiler is the one that locked that file). A capability system is better, although it would be possible to do both, since locks (and transactions as well) are also helpful for other purposes.