The closest past related works to ours are BSD-4.4 umapfs and the older and now defunct user-level NFS server for Linux, Unfsd [5]. BSD-4.4 umapfs works on the client and is not enforced by the server; thus credentials cannot be controlled by the server and this solution is not as secure as our server-side range-mapping. The Linux Unfsd server included extensions that supported UID and GID mapping or squashing via NIS or an external RPC server called ugidd. This user-level NFS server had several serious deficiencies: it was slow due to context switches and data copies between user level and the kernel; it did not reliably support many important features such as the RPC LOCKD protocol; and it had several security flaws that could not be solved unless the server ran in kernel mode. For those reasons current versions of Linux include a kernel-mode NFS server named kNFSd. When that server code was written (from scratch), it did not include support for range-mapping. Our work has added support for range-mapping, squashing, and cloaking into the Linux kernel. We achieved good performance while offering flexible features that were not available before (e.g., cloaking), not even in Unfsd.
Today's NFS servers include a feature to suppress access from UID 0 or GID 0, also known as root squashing [2,22,12,17]. Linux also includes a feature called all squashing that maps all incoming UIDs or GIDs to a single number. As we saw in the design section, our work is a superset of these forms of UID or GID squashing (root or all). With file-cloaking, we support a superset of masking features that includes the ability to disable SETUID or SETGID binaries from executing over NFS.
NFS runs on top of RPC (Remote Procedure Calls) and it is possible to secure NFS by securing the RPC layer. Several secure-RPC systems exist that support even strongly-secure systems such as Kerberos [1,9,21]. Unfortunately, past secure RPC systems used with NFS did not always interoperate well with each other and are not available for all existing NFS implementations. To use a system such as Kerberos, NFS clients, servers, and even some user applications have to be modified to support Kerberos; consequently, most NFS systems use the weaker form of user authentication known as AUTH_UNIX, where NFS clients inform the servers what UID and GID they use. Even with strong RPC security, NFS servers still do not support features such as cloaking and range-mapping. Our work does not aim to replace strong security, but rather to show how additional access methods that improve security can be implemented and deployed easily, and that these changes have little effect on overall performance.
A newer version of the protocol, NFSv4, promises to support many new features including mandatory strong security, protocol extensibility, support for wide-area file access, and better interoperability between Unix and non-Unix systems [19,26]. In NFSv4, users need not be determined by their UID and GID, but by a universal identifier such as an Email address or an electronic signature. Doing so will help identify users uniquely throughout the Internet and would alleviate the need for range-mapping.
Although the current NFSv4 specification does not support cloaking, the protocol was designed for extensibility. Our cloaking techniques do not require a change in the NFS protocol and can be implemented in exactly the same way: our work is therefore compatible with NFSv4 as well as with older NFS protocols. However, as discussed in Section 3.2, our cloaking implementation may be configured to force NFS clients not to cache file attributes or use them, to ensure the correctness of the data that is given to different users on the same client. This costs in performance as we saw in Section 4.4. With NFSv4, cloaking could be added easily as extensions to the protocol that cooperative NFSv4 clients and servers can agree on dynamically. An NFSv4 server can allow an NFSv4 client to cache these entries. If another user tries to list a directory that is cached on the server, the server can then issue a callback request to the client (now acting as a small server for these RPC callbacks) to flush the cache before the server sends the client a list of files for that directory; this new list can be different based on the particular view of that directory for another user.
NFSv4 also supports Access Control Lists (ACLs) as optional file attributes. ACLs are also possible with NFSv3, but they are not part of the specification and not all vendors implement ACL support. The reason is that not all operating systems and file systems support ACLs, and those that do are often incompatible (for example, one system supports ACLs only for directories and another system supports them for any file). Whereas ACLs can be an effective and powerful access-control mechanism and are compatible with our cloaking techniques, ACL support remains an optional feature of existing and future NFS protocols.
NFSv2 was widely used in 1994, when NFSv3 was introduced. The protocol has not changed fundamentally: two defunct RPC operations were removed and a few more added; support for TCP and 64-bit files was included too. Still, it took several years before most major vendors began supporting NFSv3 and a few more years to stabilize their code. Today, eight years later, not all vendors who support NFSv2 also support NFSv3, and of those that do, interoperability and stability problems remain. In comparison, NFSv4 represents a large departure from NFSv3: the now stateful protocol integrates all previous RPC services needed to support NFS (such as MOUNTD, LOCKD, and more) and the specification is larger too. The NFSv4 RFC is 212 pages, compared with only 126 pages for the NFSv3 RFC. We expect that it would be several years before NFSv4 is deployed by all vendors and is stable. Even then, older versions of NFS are likely to remain in use. For those reasons, we believe that the work we presented in this paper remains viable for the foreseeable future.
There are several commercial products that can map credentials transparently, such as Network Appliances's filer [10]. Also, AFS [4] can map users transparently by referring to their usernames. However, these solutions are often expensive, are not available as Open Source Software, or not in wide use compared to Linux and NFS.