The main contribution of this work is to allow NFS servers to export their file systems to hosts they would not have allowed access before for security reasons. We used two techniques: range-mapping and file-cloaking.
Range-Mapping translates UIDs and GIDs of users and their files between NFS servers and clients that exist on different administrative domains. This lets users access their files on different sites where their user accounts have different credentials. File-cloaking prevents certain files from being seen or accessed by some users. This lets administrators and users control the accessibility and visibility of their files. One use of this is to allow only the files' owners to see their own files; or to prevent world-writable or SETUID files from being seen or accessed by anyone other than their owners; or ensuring that only members of the same Unix group could see and write to a shared file. Cloaking gives administrators the flexibility to safely export multi-user file systems to clients of a single user where that user may not be trusted with the remaining files on the exported volume.
We designed and implemented this work to be contained entirely inside the NFS server and require no changes to the NFS protocol or clients. This ensured that our work can interoperate with all existing NFS clients without modification.
Special care was taken to ensure that performance of our system was good and that kernel resource consumption remained low. Our benchmarks show a good performance even with a large number of range-mapping and file-cloaking entries in use.
Cloaking is a feature that is useful not just for NFS but for all file systems. We plan on moving our cloaking code to the Virtual File System (VFS) [6,15]. This way, cloaking features could be used with other native file systems such as EXT2FS on local hosts, or with stackable file systems [3,20,27,28,30], as well as NFS and other network-based file systems.
We plan to explore methods to improve the performance of cloaking. To improve cloaking performance, we have to allow multi-user NFS clients to cache files. However, the VFS's directory cache is not aware of which users are looking up entries in the cache. If one user lists a directory, all the files in that directory are cached and can be seen by another user that can list the same directory. For cloaking to work with caching, we need to support user views of the directory cache. That is, each entry in the client-side cache should have enough information about cloaking to determine how to present the contents of a directory to a user based on their immediate credentials, filtering files that they should not see or access. To achieve this, it would be important to change the directory cache and the VFS in a way that does not change existing NFS protocols.
An alternative to changes to the directory cache is to implement cloaking functionality in both the NFS server and the client. However, changing many existing NFS clients is impractical and changing NFS protocols in use is nearly impossible. A more suitable platform for such changes would be NFSv4 as we discussed in Section 5. NFSv4 standardizes the mechanisms to extend the protocol and provides callback methods for servers to initiate contact with clients. In this way we can allow clients to cache directories that were filtered due to cloaking, and force new client-side users to contact the server to get an updated list of files for a directory, based on a different view of that directory for the new user.