Administrators must set up initial NFS mountpoints on each client for each server that offers DisCFS services. To construct a secure path to the DisCFS server, the client constructs an IPsec tunnel between the client system and the DisCFS server. We extended the NFS protocol with an RPC procedure that enables the client to attach the remote directory to the mountpoint over the IPsec connection. This allows the DisCFS server to retrieve the public key used for authentication in the IKE [13] protocol (as part of the IPsec key establishment phase) and associate it with a Unix-style userid . IPsec protects future NFS requests, allowing the DisCFS server to associate them with the user's public key. Each user on a multi-user client has his own IPsec connection to the server.
After a user executes our RPC attach procedure, the desired directory appears under the client's default DisCFS mount point (e.g., /discfs ). However, because the user has not yet provided any credentials, the file permissions of the attached directory are set to deny all access. File/directory ownership is set to the userid provided by the attach procedure. The userid is irrelevant to the DisCFS server, and thus no prior arrangement with the system administrator is needed. Similarly, no file ownership conflicts are possible; the userid is only manipulated in this way to make possible the use of unmodified NFS clients.
To get access to the attached directory or any other files/directories in it, the user must have a credential like the one shown in Figure 3. This credential is issued by the administrator (as identified by the public key appearing in the Authorizer field) to a specific user (as identified by the public key appearing in the Licensees field), and contains enough information for the DisCFS server to determine what permissions should be granted to the client system.
A file/directory is identified by a handle , which in our prototype implementation is simply the i-node number of the file/directory on the server. A DisCFS server uses this handle to locate the physical file in its local file storage. The handle specifics should change in the future because inode numbers are not suitable as globally unique identifiers across a network. A possible solution would be to build a handle from the inode number and a generation number , similar to the 4.4 BSD NFS implementation. In the following discussion we refer to file handles used by DisCFS as DisCFS file handles to distinguish them from NFS file handles.
The ``Conditions'' field can contain additional restrictions e.g., allowing access during working hours, specifying that multiple authorizers are required, etc. By combining credentials with different policy assertions we construct a rich access framework that allows fine grained access control.
The credential assertions in our implementation grant standard Unix permissions. The return values for the assertions form a partial order of 8 combinations ( ``false'', ``X'', ``W'', ``WX'', ``R'', ``RX'', ``RW'' and ``RWX'') and translate directly into the standard octal representation. Thus, in the credential of Figure 3 the user is granted read, write, and execute access on the testdir directory. We wrote a utility which allows a user to submit credential assertions to the DisCFS daemon over RPC. The DisCFS server adds credential assertions to a persistent session. Following this operation, the permissions of the attached directory change accordingly. To improve performance, we use a simple round-robin cache of requested operations and policy results.
The semantics of some of the procedures defined by the NFS protocol change in our implementation. For example, because access control is managed through credential assertions, it makes no sense to use the setattr procedure for setting mode bits on a file. There is also a problem with the create and mkdir procedures. A user can create a file in the attached directory because he has read, write, and execute access. However, he cannot access the newly created file because he does not have a credential assertion for it. Thus, we added our own RPC procedures to the NFSv2 protocol that, upon successful creation of a file/directory, return a credential with full access to the creator of the file. Furthermore, this credential is also added to the user's active session, so he can immediately use the newly-created filesystem object. The owner can then issue other credentials further delegating access to this file/directory to other users.