Installation guide

254 Chapter 17. Network File System (NFS)
17.4.1. Host Access
NFS controls who can mount an exported file system based on the host making the mount request, not
the user that will actually use the file system. Hosts must be given explicit rights to mount the exported
file system. Access control is not possible for users, other than file and directory permissions. In other
words, when you export a file system via NFS to a remote host, you are not only trusting the host you
are allowing to mount the file system. You are also allowing any user with access to that host to use
your file system as well. The risks of doing this can be controlled, such as requiring read-only mounts
and squashing users to a common user and group ID, but these solutions may prevent the mount from
being used in the way originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS
file system, the system associated with a particular hostname or fully qualified domain name can be
pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to
mount the NFS share, since no username or password information is exchanged to provide additional
security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups
are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this
kind of attack is more difficult.
Wildcards should be used sparingly when granting host access to an NFS share. The scope of the
wildcard may encompass systems that you may not know exist and should not be allowed to mount
the file system.
17.4.2. File Permissions
Once the NFS file system is mounted read-write by a remote host, protection for each shared file
involves its permissions, and its user and group ID ownership. If two users that share the same user
ID value mount the same NFS file system, they will be able to modify each others files. Additionally,
anyone logged in as root on the client system can use the su - command to become a user who could
access particular files via the NFS share.
The default behavior when exporting a file system via NFS is to use root squashing. This sets the user
ID of anyone accessing the NFS share as the root user on their local machine to a value of the server’s
nobody account. You should never turn off root squashing unless multiple users with root access to
your server does not bother you.
If you are only allowing users to read files via your NFS share, consider using the all_squash
option, which makes every user accessing your exported file system to take the user ID of the nobody
user.
17.5. Additional Resources
Administering an NFS server can be a challenge. Many options, including quite a few not mentioned
in this chapter, are available for exporting NFS file systems or mounting them as a client. Consult
these sources of information for more details.
17.5.1. Installed Documentation
/usr/share/doc/nfs-utilrs-
version-number — Covers the way NFS is implemented
in Linux, including a look at various NFS configurations and their impact on file transfer perfor-
mance.
The following man pages are very helpful:
mount Contains a comprehensive look at mount options for both NFS server and client con-
figurations.