We will eliminate the requirement to administer NFS mount points by including the name of the server hosting a file in the credential. It will then not be necessary to use the mountd protocol in order to determine a file's location. KeyNote queries will be made on all NFS calls, so that we do not have to trust the client software.
As mentioned previously, the choice of inode numbers as file handles was not optimal. Consider the case where Bob creates and shares file song.mp3 with Alice. Bob soon gets tired of the song, deletes it, and proceeds to create another file, tax_return.dat. If the inode of song.mp3 happened to be used for tax_return.dat, Alice might be granted access beyond the initial intent. To improve security, the new file handles will not use inodes.
To simplify semantics, our second prototype will not be used for sharing directories. The next version of DisCFS will support sharing of files only. Users will be able to choose what directory structure they want the files to appear in. Manual sending of credentials will be eliminated by using a loopback NFS server or a stackable filesystem layer on the client. When a file containing a credential is encountered (e.g., Makefile.cred), the loopback server will translate the name (Makefile), read the credential, connect to the remote server specified in the credential, and finally serve the file if the remote server grants access. While this additional layer will hurt performance somewhat, it will greatly enhance the transparency of DisCFS to the end user.
For our first prototype we chose a user-level NFS server because it made development a lot faster. Our benchmarks suggest that the additional context switching overhead compared to a kernel-level server is not substantial. In the future we might try to move the DisCFS server into the kernel which would likely bring about a small improvement in performance at the expense of portability. However, we suspect that larger benefits can be obtained by incorporating some of the NFS optimizations not incorporated in DisCFS (e.g., block prefetching).
DisCFS is based on NFSv2 because we had convenient examples of userland servers implementing it. It would be worthwhile to integrate our authentication and authorization model with NFSv4, e.g. as a plugin into to the GSS-API [18].
We used a simple round-robin cache of policy results in our first prototype. We would like to implement a practical cache replacement algorithm and experiment more to find an optimal cache size.
Unix permission bits can be inflexible and limiting. Future versions of DisCFS could take advantage of the flexibility of credentials to provide more fine-grained access control, e.g., allow appending to a file but no truncation.
Looking further forward, new file-sharing policies are achievable with DisCFS beyond the Unix NFS support demonstrated. An example of such use would be enabling controlled access to file storage for the untrusted users that are characteristic of the Web. DisCFS should also offer advantages for emerging P2P systems, as its avoidance of centralized control is well-suited to cooperative resource-sharing at a large scale and with disparate administrative models. Finally, while DisCFS's decentralized control should result in ``scalability'', this assertion requires robust quantitative modeling and supporting measurement.