All of these access-matrix entities are still relevant in a distributed system such as AFS, though their implementation, as we shall see below, may change significantly. For instance, network file systems supports an access matrix that includes both local and remote files as protected objects. In addition, several additional access-matrix entities can be defined in a distributed system:
Servers as Protected Objects: A remote server can be made a protected object, guarding access to resources managed by it. For instance, the X window server is a protected object, associated with a connect right. Only a client with this right can connect to the server to manipulate the display managed by it.
Hosts as Subjects: A host name can be considered a subject that defines the rights common to all processes executing on that host. For instance, in X, host names are used to specify the clients that can connect to an X server. The idea of making host names as subjects is useful because hosts are often associated with trusted users or institutions.
Distributed Rights: In a distributed system, an operation on a remote site requires two sub operations: (1) transmission of the operation parameters to the remote site and (2) invocation of the operation on the remote site. For instance, updating a remote replica with local information involves (1) sending local changes to the remote site and (2) applying those changes at the remote site. Should a single (logically) centralized right protect the complete operation or two different distributed rights, one at each site, be used to protect each suboperation? Thus, in the example above, should we define a single right for the replication step, or a separate right on the local object to determine if changes to it can be sent to the remote location and a separate right on the remote object determining if these changes can be applied to it? In a single-site system, it is typical for a complete, user-level operation to be associated with a single right. However, in our example above, if the distriibuted sites are considered autonomous, then the second approach is more appropriate
Replicas as Subjects and Protected Objects, Replicated Rights: As we can see from the example above, in a replicated system, a replica can be both a subject and an object, since replicas manipulate information in other replicas. For instance, in Lotus Notes, a document replica can have read or write rights to another replica , which allow it to copy and modify, respectively, the remote object The rights of replicas may themselves be replicated to ensure access-control consistency across multiple sites.
Users as Protected Subjects and Objects: Similarly, in a collaborative system, users can be both subjects and protected objects, since they exchange information with each other. For instance, in the Suite collaborative system, users have rights to send information to or receive information from other users, with separate rights for synchronous and asynchronous collaboration.
Procedures as Subjects and Objects: In a system supporting dynamic code downloading, we might want control over the kind of procedures that are downloaded to a host and the actions they perform on the host. The downloaded code can execute as procedures (e.g. applets) invoked by an existing process on the host. Therefore, it may not be sufficient to let its rights be determined by the local user who started the process. Instead, most web-based browsers use the identity of the downloaded procedure, or some authority, called a principal, that has signed it, as the subject whose rights are checked when the code is executed.
Beyond File Rights: Single-site systems provide use file rights such as read/write/execute for protecting all resources. As we have seen above, distributed systems protect additional kinds of objects such as hosts and users whose properties are not captured by memory or files. Therefore, they also support additional, application-specific, rights such as the connect, send and receive rights we saw earlier.