 | Level: Introductory Frank Pohlmann (frank@linuxuser.co.uk), Linux user and developer, Freelance
Kenneth Hess (kenneth.hess@gmail.com), Linux user, advocate, and author, Freelance
12 Sep 2006 Network File System (NFS) has been part of the world of free operating systems and proprietary UNIX® flavors since the mid-1980s. But not all administrators know how it works or why there have been new releases. A knowledge of NFS is important simply because the system is vital for seamless access across UNIX networks. Learn how the latest release of NFS, NFSv4, has addressed many criticisms, particularly with regard to security problems, that became apparent in versions 2 and 3.
We take file systems for granted. We work on computers that give us access to printers, cameras, databases,
remote sensors, telescopes, compilers, and mobile phones. These devices share few characteristics -- indeed,
many of them became a reality only after the Internet became universal (for example, cameras and mobile phones
that combine the functions of small computers). However, they all need file systems of some type to store and
order data securely.
Typically, we don't really ask how the data, the applications consuming it, and the interfaces presenting the data
to us are stored on the computers themselves. Most users would (not unjustifiably) regard a file system as the
wall separating them from the bare metal storing bits and bytes. And the protocol stacks connecting file systems
usually remain black boxes to most users and, indeed, programmers. Ultimately, however, internetworking all these
devices amounts to enabling communication between file systems.
Networking file systems and other holy pursuits
In many ways, communication is little more than a long-distance copying of information. Network protocols were
not the only means by which universal communications became possible. After all, every computer system must
translate datagrams into something the operating system at the other end understands. TCP is a highly effective
transmission protocol, but it's not optimized to facilitate fast access to files or to enable remote control
of application software.
Distributed vs. networked computations
Traditional networking protocols don't have much to contribute to the way in which computations are distributed
across computers and, indeed, networks. Only foolish programmers would rely on transmission protocols and
fiber-optic cables to enable parallel computations. Instead, we typically rely on a serial model, in which
link-level protocols take over after connections are initiated and have performed a rather complex greeting
between network cards. Parallel computations and distributed file systems are no longer aware of IP or Ethernet.
Today, we can safely disregard them as far as performance is concerned. However, security problems are a
different matter.
One piece of the puzzle is the way file access is organized across a computer system. Now, it's
irrelevant to the accessing system whether the accessed files are available on one or on several presumably
rationally distributed computers. File system semantics and file system data structures are two very different
topics these days. File system semantics on a Plan 9 installation or on an Andrew File System (AFS)-style
distributed file system hide the way in which files are organized or how the file system maps to hardware
and networks. NFS does not necessarily hide the way in which files and directories are stored on remote
file systems, but it doesn't expose the actual hardware storing the file systems, directories, and files,
either.
NFS: A solution to a UNIX problem
Distributed file system access, therefore, needs rather more than a couple of commands enabling users to mount
a directory on a computer networked to theirs. Sun Microsystems faced up to this challenge a number of years ago when
it started propagating something called Remote Procedure Calls (RPCs) and NFS.
The basic problem that Sun was trying to solve was how to connect several UNIX computers to form a seamless
distributed working environment without having to rewrite UNIX file system semantics and without having to add
too many data structures specific to distributed file systems. Naturally, it was impossible for a network of
UNIX workstations to appear as one large system: the integrity of each system had to be preserved while still
enabling users to work on a directory on a different computer without experiencing unacceptable delays or
limitations in their workflow.
To be sure, NFS does more than facilitate access to text files. You can distribute "runnable" applications through
NFS, as well. Security procedures serve to shore up the network against the malicious takeovers of executables. But
how exactly does this happen?
NFS is RPC
NFS is traditionally defined as an RPC application requiring TCP for the NFS server and either TCP or another
network congestion-avoiding protocol for the NFS client. The Internet Engineering Task Force (IETF) has published
the Request for Comments (RFC) for RPCs in RFC 1832. The other standard vital to the functioning of an NFS
implementation describes data formats that NFS uses; it has been published in RFC 1831 as the "External Data
Representation" (XDR) document.
Other RFCs are relevant to security and the encryption algorithms used to exchange authentication information
during NFS sessions, but we focus on the basic mechanisms first. One protocol that concerns us is the Mount
protocol, which is described in Appendix 1 of RFC 1813.
This RFC tells you which protocols make NFS work, but it doesn't tell you how NFS works today. You've
already learned something important by knowing that NFS protocols have been documented as IETF standards.
While the latest NFS release was stuck at version 3, RPCs had not progressed beyond the informational RFC
stage and thus were perceived as an interest largely confined to Sun Microsystems' admittedly huge engineering
task force and proprietary UNIX variety. Sun NFS has been around in several versions since 1985 and, therefore,
predates most current file system flavors by several years. Sun Microsystems turned over control of NFS to the
IETF in 1998, and most NSF version 4 (NFSv4) activity occurred under the latter's aegis.
So, if you're dealing with RPC and NFS today, you're dealing with a version that reflects the concerns of
companies and interest groups outside Sun's influence. Many Sun engineers, however, retain a deep interest in
NFS development
NFS version 3
NFS in its version 3 avatar (NFSv3) was not stateful: NFSv4 is. This fundamental statement is unlikely to raise any
hackles today, although the TCP/IP world on which NFS builds has mostly been stateless -- a fact that has helped
traffic analysis and security software companies do quite well for themselves.
NFSv3 had to rely on several subsidiary protocols to seamlessly mount directories on remote computers without becoming
too dependent on underlying file system mechanisms. NFS has not always been successful in this attempt. To give you
a better example, the Mount protocol called the initial file handle, while the Network Lock Manager protocol addressed
file locking. Both operations required state, which NFSv3 did not provide. Therefore, you have complex interactions
between protocol layers that do not reflect similar data-flow mechanisms. Now, if you add the fact that file and
directory creation in Microsoft® Windows® works very differently from UNIX, matters become rather
complicated.
NFSv3 had to use several ports to accommodate some of its subsidiary protocols, and you get a rather complex picture
of ports and protocol layers and all their attendant security concerns. Today, this model of operation has been
abandoned, and all operations that subsidiary protocol implementations previously executed from individual ports
are now handled by NFSv4 from a single, well-known port.
NFSv3 was also ready for Unicode-enabled file system operation -- an advantage that until the late 1990s had to remain
fairly theoretical. In all, it mapped well to UNIX file system semantics and motivated competing distributed file
system implementations like AFS and Samba. Not surprisingly, Windows support was poor, but Samba file servers have
since addressed file sharing between UNIX and Windows systems.
NFS version 4
NFSv4 is, as we pointed out, stateful. Several radical changes made this behavior possible. We already mentioned that
subsidiary protocols must be called, as user-level processes have been abandoned. Instead, every file-opening
operation and quite a few RPC calls are turned into kernel-level file system operations.
All NFS versions defined each unit of work in terms of RPC client and server operations. Each NFSv3 request required
a fairly generous number of RPC calls and port-opening calls to yield a result. Version 4 simplifies matters by
introducing a so-called compound operation that subsumed a large number of file system object operations.
The immediate effect is, of course, that far fewer RPC calls and data have to traverse the network, even though
each RPC call carries substantially more data while accomplishing far more. It is estimated that NFSv3 RPC calls
required five times the number of client-server interactions that NFSv4 compound RPC procedures demand.
RPC is not really that important anymore and essentially serves as a wrapper around the number of operations
encapsulated within the NFSv4 stack. This change also makes the protocol stack far less dependent on the underlying
file system semantics. But the changes don't mean that the file system operations of other operating systems were
neglected: For example, Windows shares require stateful open calls. Statefulness not only helps traffic analysis
but, when included in file system semantics, makes file system operations much more traceable. Stateful open
calls enable clients to cache file data and state -- something that would otherwise have to happen on the server.
In the real world, where Windows clients are ubiquitous, NFS servers that work seamlessly and transparently with
Windows shares are worth the time you'll spend customizing your NFS configuration.
Using NFS
NFS setup is generically similar to Samba. On the server side, you define file systems or directories to export,
or share; the client side mounts those shared directories. When a remote client mounts an NFS-shared directory,
that directory is accessed in the same way as any other local file system. Setting up NFS from the server side is
an equally simple process. Minimally, you must create or edit the /etc/exports file and start the NFS daemon. To set up a
more secure NFS service, you must also edit /etc/hosts.allow and /etc/hosts.deny. The client side of NFS requires
only the mount command. For more information and options, consult the Linux® man
pages.
The NFS server
Entries in the /etc/exports file have a straightforward format. To share a file system, edit the /etc/exports
file and supply a file system (with options) in the general format:
directory (or file system) client1 (option1, option2) client2 (option1, option2)
|
General options
Several general options are available to help you customize your NFS implementation. They include:
secure: This option -- the default -- uses available TCP/IP ports
below 1024 for NFS connections. Specifying insecure disables this option.rw: This option allows NFS clients read/write access. The default option
is read only.async: This option may improve performance, but it can also cause
data loss if you restart the NFS server without first performing a clean shutdown of the NFS daemon.
The default setting is sync.no_wdelay: This option turns off the write delay. If you set
async, NFS ignores this option.nohide: If you mount one directory over another, the old directory is
typically hidden or appears empty. To disable this behavior, enable the hide
option.no_subtree_check: This option turns off subtree checking, which performs
some security checks that you may not want to bypass. The default option is to have subtree checks enabled.no_auth_nlm: This option, also specified as insecure_locks,
tells the NFS daemon not to authenticate locking requests. If you're concerned about security, avoid this
option. The default option is auth_nlm or secure_locks.mp (mountpoint=path): By explicitly declaring this option, NSF requires
that the exported directory be mounted.fsid=num: This option is typically used in NFS failover scenarios. Refer
to the NFS documentation if you want to implement NFS failover.
User mapping
Through user mapping in NFS, you can grant pseudo or actual user and group identity to a user working on an NFS
volume. The NFS user has the user and group permissions that the mapping allows. Using a generic user and
group for NFS volumes provides a layer of security and flexibility without a lot of administrative overhead.
User access is typically "squashed" when using files on an NFS-mounted file system, which means that a user accesses
files as an anonymous user who, by default, has read-only permissions to those files. This behavior is especially
important for the root user. Cases exist, however, in which you want a user to access files on a remote system as
root or some other defined user. NFS allows you to specify a user -- by user identification (UID) number and group
identification (GID) number -- to access remote files, and you can disable the normal behavior of squashing.
User mapping options include:
root_squash: This option doesn't allow root user access on the mounted
NFS volume.no_root_squash: This option allows root user access on the mounted NFS
volume.all_squash: This option, which is useful for a publicly accessible NFS
volume, squashes all UIDs and GIDs and only uses the anonymous account. The default setting is
no_all_squash.anonuid and anongid: These options change the
anonymous UIDs and GIDs to specific user and group accounts.
Listing 1 shows examples of /etc/exports entries.
Listing 1. Example /etc/exports entries
/opt/files 192.168.0.*
/opt/files 192.168.0.120
/opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100)
/opt/files *(ro, insecure, all_squash)
|
The first entry exports the /opt/files directory to all hosts in the 192.168.0 network. The next entry exports
/opt/files to a single host: 192.168.0.120. The third entry specifies host 192.168.0.125 and grants read/write
access to the files with user permissions of user id=210 and group id=100.
The final entry is for a "public" directory that has read-only access and allows access only under the anonymous
account.
The NFS client
|
A word of caution
After you have used NFS to mount a remote file system, that system will also be part of any total system backup that you
perform on the client system. This behavior can have potentially disastrous results if you don't exclude the newly mounted
directories from the backup.
|
|
To use NFS as a client, the client computer must be running rpc.statd and portmap. You can run a quick
ps -ef to check for these two daemons. If they are running (and they should be), you can
mount the server's exported directory with the generic command:
mount server:directory local mount point
|
Generally speaking, you must be running under root to mount a file system. From a remote computer, you can use the
following command (assume that the NFS server has an IP address of 192.168.0.100):
mount 192.168.0.100:/opt/files /mnt
|
Your distribution may require you to specify the file system type when mounting a file system. If so, run the command:
mount -t nfs 192.168.0.100:/opt/files /mnt
|
The remote directory should mount without issue if you've set up the server side correctly. Now, run the
cd command to the /mnt directory, then run the ls command
to see the files. To make this mount permanent, you must edit the /etc/fstab file and create an entry similar to
the following:
192.168.0.100:/opt/files /mnt nfs rw 0 0
|
Note: Refer to the fstab man page for more information on /etc/fstab entries.
NFS criticisms
|
Criticism drives improvement
Criticisms leveled at NFS security have been at the root of many improvements in NSFv4. The designers of the new
version took positive measures to strengthen the security of NFS client-server interaction. In fact, they decided to
include a whole new security model.
To understand the security model, you should familiarize yourself with something called the Generic Security
Services application programming interface (GSS-API) version 2, update 1. The GSS-API is fully described in RFC
2743, which, unfortunately, is among the most difficult RFCs to understand.
We know from our experience with NFSv4 that it's not easy to make the network file system operating system independent.
But it's even more difficult to make all areas of security operating systems and network protocols independent. We
must have both, because NFS must be able to handle a fairly generous number of user operations, and it must do so
without much reference to the specifics of network protocol interaction.
Connections between NFS clients and servers are secured through what has been rather superficially called strong
RPC security. NFSv4 uses the Open Network Computing Remote Procedure Call (ONCRPC) standard codified in RFC 1831.
The security model had to be strengthened, and instead of relying on simple authentication (known as AUTH_SYS),
a GSS-API-based security flavor known as RPCSEC_GSS has been defined and implemented as a mandatory part of
NFSv4. The most important security mechanisms available under NFSv4 include Kerberos version 5 and LIPKEY.
Given that Kerberos has limitations when used across the Internet, LIPKEY has the pleasant advantage of working like
Secure Sockets Layer (SSL), prompting users for their user names and passwords, while avoiding the TCP dependence of
SSL -- a dependence that NFSv4 doesn't share. You can set NFS up to negotiate for security flavors if RPCSEC_GSS is
not required. Past NFS versions did not have this ability and therefore could not negotiate for the quality of
protection, data integrity, the requirement for authentication, or the type of encryption.
|
|
NFSv3 had come in for a substantial amount of criticism in the area of security. Given that NFSv3 servers ran on TCP,
it was perfectly possible to run NFSv3 networks across the Internet. Unfortunately, it was also necessary to open
several ports, which led to several well-publicized security breaches. By making port 2049 mandatory for NFS, it
became possible to use NFSv4 across firewalls without having to pay too much attention to what ports other protocols,
such as the Mount protocol, were listening to. Therefore, the elimination of the Mount protocol had multiple positive
effects:
- Mandatory strong authentication mechanisms: NFSv4 makes strong authentication mechanisms mandatory.
Kerberos flavors are fairly common, and Lower Infrastructure Public Key Mechanism (LIPKEY) must be supported,
as well. NFSv3 never supported much more than UNIX-style standard encryption to authenticate access -- something
that led to major security problems in large networks.
- Mandatory Microsoft Windows NT-style access control list (ACL) schemes: Although NFSv3 allowed
for strong encryption for authentication, it did not push Windows NT-style ACL access schemes. Portable Operating
System Interface (POSIX)-style ACLs were sometimes implemented but never widely adopted. NFSv4 makes Windows NT-style
ACL schemes mandatory.
- Negotiated authentication styles and mechanisms: NFSv4 makes it possible to negotiate authentication
styles and mechanisms. Under NSFv3, it was impossible to do much more than determine manually which encryption
styles were used. The system administrator then had to harmonize encryption and security protocols.
Is NFS still without peers?
NFSv4 is replacing NFSv3 on most UNIX and Linux systems. As a network file system, NSFv4 has few competitors. The
Common Internet File System (CIFS)/Server Message Block (SMB) could be considered a viable competitor given that it's
native to all Windows varieties and (today) to Linux. AFS never made much commercial impact, and it emphasized elements
of distributed file systems that made data migration and replication easier.
Production-ready Linux versions of NFS had been around since the kernel reached version 2.2, but one of the more common
failings of Linux kernel versions was the fact that Linux adopted NFSv3 fairly late. In fact, it took a long time
before Linux fully supported NSFv3. When NSFv4 came along, this lack was addressed quickly, and it wasn't just Solaris,
AIX, and FreeBSD that enjoyed full NSFv4 support.
NFS is considered a mature technology today, and it has a fairly big advantage: It's secure and usable, and most users
find it convenient to use one secure logon to access a network and its facilities, even when files and applications
reside on different systems. Although this might look like a disadvantage compared to distributed file systems, which
hide system structures from users, don't forget that many applications use files from different operating systems and,
therefore, computers. NFS makes it easy to work on different operating systems without having to worry too much about
the file system semantics and their performance characteristics.
Resources Learn
Get products and technologies
-
OpenAFS is the open source version of AFS, another distributed file system.
-
SAMBA can be regarded as a file system and can fulfill some of the roles of NFS.
About the authors | 
| | Frank Pohlmann dabbled in the history of Middle Eastern religions before various funding committees decided that research in the history of religious polemics was quite irrelevant to the modern world. He has focused on his hobby -- free software -- ever since. He admits to being the technical editor of the U.K.-based LinuxUser and Developer. |
| 
| | Ken Hess is a long-time Linux user and enthusiast. He started the Linux User's Group in Tulsa, Oklahoma, in 1996 and writes on a variety of Linux and open source topics. Ken stays busy with his day job, his family, and his art. |
Rate this page
| |
