| Next: Multi-threaded Applications | Prev: Portal Addressing | Up: Overview Contents |
A process can control access to its Portals using an access control list. Each entry in the access control list specifies a process id, possibly a job id, a user id, and a Portal table index. The access control list is actually an array of entries. Each incoming request includes an index into the access control list (i.e., a "cookie" or hint). If the id of the process issuing the request doesn't match the id specified in the access control list entry or the Portal table index specified in the request doesn't match the Portal table index specified in the access control list entry, the request is rejected. Process identifiers, job identifiers, user identifiers, and Portal table indexes may include wildcard values to increase the flexibility of this mechanism.
Two aspects of this design merit further discussion. First, the model assumes that the information in a message header, the sender's process id, node id, user id, and job id in particular, is trustworthy. In most contexts, we assume that the entity that constructs the header is trustworthy; however, using cryptographic techniques, we could easily devise a protocol that would ensure the authenticity of the sender.
Second, because the access check is performed by the receiver, it is possible that a malicious process will generate thousands of messages that will be denied by the receiver. This could saturate the network and/or the receiver, resulting in a \emph{denial of service} attack. Moving the check to the sender using capabilities, would remove the potential for this form of attack. However, the solution introduces the complexities of capability management (exchange of capabilities, revocation, protections, etc).