My next question relates to how capabilities are granted in the first place. When I obtain a capability against an object o, does the owner of o not apply an access list type mechanism to determine if the capability should be granted?
This is a good question, but it has a lot of assumptions buried in it. You've really hit three distinct topics:
Let me take each in turn:
Here is how it works in EROS:
Objects are *not* created. Ultimately, all the objects you are ever going to have are already there -- the pages and nodes (fixed-length capability arrays) on the disk. What happens is that some agent comes along, purchases some unallocated pages and nodes from a storage manager (known as a space bank), arranges those objects in a useful way, and hands you a capability to the arrangement.
As you get close to the disk, there are a few construction agents that
are trusted system services. Not too far above that are mechanism
that let *me* describe how to build an object for *you* to use, in
such a way that *you* will provide the space for your instance of the
object and the construction agent (called, not surprisingly, a
"constructor") makes some guarantees to you about the security of the
object.
The space bank, obviously, is trusted code.
In other systems, the kernel dynamically allocates a new object for you out of available memory or swap space.
In either design, you initially become the sole holder of a capability to the new object, because part of the contract is that the constructor won't give that capability to anyone else.
2. Granting Capabilities
If you are the only program who holds a capability, you are in complete control of who gets a copy of it. You can do this however you wish -- by building an access list, by giving it only to selected objects that work for you, by random distribution, or by some other means. An ACL is merely one of the mechanisms you might use.
For some objects, it is possible to create "weaker" capabilities (e.g. a read-only memory object) from the initial capability, and you can give those out instead.
This begs the question of how you arrive at your initial set of capabilities that lets you build other objects. Briefly, the answer is that every user account receives at it's creation a directory of initial capabilities. Typically, this directory holds capabilities to various services, along with the user's per-user storage manager.
So how do you know who to give things to?
You can only transmit a capability by invoking some other capability that you already have. Presumably, you know what is on the other end of those capabilities and don't give away anything unwise, in the same way that you don't leave your key in your front door when you leave the house.
3. Ownership
If two parties hold the same capability, they have the same authority. In this sense, they are equally "owners" of the object that the capability names.
In a system with properly accounted storage, the party who originally paid for the storage is "more equal", in the sense that they are able to reclaim the storage out from under the other parties. This is essential if accounting is to be done properly.
The alternative to an explicit storage design is garbage collection. The problem with this is that you cannot account for the storage correctly.
Back to the key example: utimately the building owner would apply a ACL type mechanism to determine whether to give me a building key.
I think I answered this in the last mail. Basically, an access control list mechanism is built on top of a capability mechanism.
shap