12.8 The State of Network File Sharing
At this point, you might feel that this discussion of the NFS and file sharing in general seems somewhat incomplete—and it might be, but only as much as the file sharing systems themselves. We discussed performance and security concerns in Sections 12.3.1 and 12.3.2. In particular, the base security level of NFS is quite low, requiring significant extra work to improve. CIFS systems are somewhat better in this regard, as the necessary encryption layers are built into contemporary software. However, performance limitations aren’t easy to overcome, not to mention how badly a system can perform when it is temporarily unable to access its network storage.
There have been several attempts to deal with this issue. Perhaps the most extensive is the Andrew File System (AFS), first designed in the 1980s, which was built around solutions to these problems. So why doesn’t everyone use AFS or something like it?
There is no one answer to this question, but much of it comes down to a certain lack of flexibility in some parts of the design. For example, the security mechanism requires a Kerberos authentication system. Though universally available, it has never been standard on Unix systems, and requires a nontrivial amount of work to set up and maintain (you have to set up a server for it).
For a large institution, fulfilling requirements such as Kerberos isn’t a problem. This is exactly the setting in which AFS has thrived; universities and financial institutions are big AFS sites. But for the small user, it’s simply easier not to do it, preferring simpler options like NFS or CIFS shares. This sort of limitation even extends to Windows; starting with Windows 2000, Microsoft switched to Kerberos as the default authentication on its server product, but small networks don’t tend to be Windows domains with this kind of server.
Aside from the authentication prerequisite, there’s a problem that stems from more technical reasons. Many network filesystem clients have traditionally been kernel code, NFS in particular. Unfortunately, the requirements of network filesystems are complex enough that problems start to occur. The authentication alone has no place in the kernel. A kernel client implementation also severely limits the potential developer base for a network filesystem, hampering the system as a whole. In some cases, client code was in user space, but there was always some sort of kernel customization underneath.
At the moment, we find ourselves without a truly standard means of network file sharing in the Linux/Unix world (at least if you’re not a large site or you aren’t willing to put in a fair amount of work). However, this won’t necessarily always be the case.
When providers started to offer cloud storage, it was clear that the traditional forms of network file sharing wouldn’t be suitable. In the cloud, access methods are built on top of security mechanisms such as TLS that make it possible to access storage without setting up a large system such as Kerberos. As mentioned in the preceding section, there are many options available via FUSE to access cloud storage. We’re no longer dependent on the kernel for any part of the client; any kind of authentication, encryption, or handling can easily be done in user space.
All of this means that the future could very well see some file-sharing designs incorporating more flexibility in security and other areas such as filename translation.