At Fri, 10 Jun 2005 16:55:05 +0200, Bernhard Kauer wrote:
Within this framework, the only directly supported operations on such capabilities are map, grant, unmap and IPC. The map operation can be used to delegate the capability, grant can be used to move the capability and unmap to revoke it. The IPC operation allows clients to send messages to an object, for example, to invoke operations on the object.
I think here is a difference to our view on capabilities: The IPC operation allows to send a message through an endpoint to a server. The server could somehow identify the sender of a message.
As we understand it, the next gneration L4 API will not offer first class capability objects. The assumption has been that capabilities will be built on top of end points. So, I think we agree: there is no fundamental equivalence between end points and capabilities and the question at hand is: how do we represent capabilities? I think we made this clean in the introduction to the original email:
Not much can be said about a capability system without first determining how capabilities are represented. The current proposals assume that server objects will be represented by communication end points (more precisely, by the receive end). The send sides of the end points then assume the role of the capability. This is not the only solution. Other primary (kernel) objects following the map/grant/unmap semantics could be used to represent objects and capabilities.
The server could somehow identify the sender of a message.
Are you suggesting that we use the task id of the sender as the key?
The problem with *simply* using the sender of the message as identification (i.e. no object key) is that it assumes that the sender is the principle. This doesn't need to be the case. Consider a trusted interpreter: it can serve many mutually untrusting clients from the same thread. If the server only uses the task id of the sender to find the principle, the interpreter will have to implement its own security architecture. This is why ambient authority does not make a good security architecture: this policy unnecessarily restricts the type of authority principles one can have. Moreover, exposing the sender to the receiver violates the principle of least information (i.e. only expose what is necessary and nothing more) and it also makes copying access to an object more difficult and requires a cooperative server.
It is possible to build a capability system using sender ids: the server becomes a capability server and provides object IDs to clients. We (primarily Marcus) did it. The resulting system is slow. The reason? The trust issues involved make the protocols very hairy. We finally abandoned the system when Marcus realized that interposing proxies (a feature we highly desire) was far too complicated: the server would need to accept capabilities from (i.e. block on) untrusted clients.
Using this sender identification as object reference, where the server invokes an operation on, is possible only if a single object reference is needed. As mentioned by Neal last week this does not work for multiple references.
I am sorry, I don't remember saying that or maybe I just don't understand what you mean.
By using the sender id as an reference for a user, this problem is gone.
To demonstrate the difference between these two attempts, look at a simple fileserver. If only read/write operations are needed the sender id could be the file number. But with an operation which needs multiple files like copying between two files, the sender id should identify only the user, but not the file anymore.
I am sorry, I don't completely understand this example. It sounds to me that you are suggesting is ACLs? Is that right?
Thanks, Neal