Setting Up Exports

Linux uses the /etc/exports file to describe the directories that an NFS server exports. Lines in this file may be comments, which begin with hash marks (#), or they may be export definitions. Each export definition takes the following form:

/directory ciient{options) [client(options)[...]\

The /directory is the directory that's to be made available, such as /home or /opt/OpenOffice.org. Following the directory are one or more client specifications. You can list clients in any of several ways:

Hostnames You can provide a computer's hostname, such as collins.luna.edu orcollins. If you omit the domain name, the server assumes you're referring to a computer in its own domain.

Wildcards If you want to export a directory to all the computers in a domain, or to certain subsets of them, you might be able to use the asterisk (*) and question mark (?) wildcards. These features work much like their equivalents in shells when used to specify filenames. They don't match dots in hostnames, though. For instance, *.Iuna.edu matches collins.luna.edu and gordon.luna.edu, but not bean.surveyor.luna.edu.

IP Addresses You can specify a computer by IP address, as in 172.24.202.7. This method is harder for humans to interpret than hostnames, but it has a security advantage because it doesn't rely on a Domain Name System (DNS) server to convert the hostname to an IP address. If you use hostnames, an attacker could conceivably gain access to your NFS server by first taking over a DNS server.

Network Addresses You can specify a network by IP address range by providing the IP address, a slash, and a netmask. The netmask can be specified either in dotted-decimal form or as the number of bits in the network portion of the address. For instance, 172.24.0.0/255.255.0.0 and 172.24.0.0/16 are equivalent.

NIS Netgroups If your network uses the Network Information System (NIS), you can specify an NIS netgroup by preceding its name with an at sign, as in ©tranquility.

Following each client specification is a comma-separated list of options. Table 24.3 summarizes the most common of these options. You can find additional options in the exports man page.

Table 24.3: Common NFS Export Options

Option

Meaning

secure or insecure

Specifies that the client must connect (secure) or need not connect (insecure) from a secure port (one numbered below 1024). The default value is secure.

rw orro

Specifies read/write (rw) or read-only (ro) client access to the export. The default in recent Linux NFS servers is ro, but some versions have usedrw. I recommend making your choice explicit to avoid the possibility of confusion.

sync orasync

The async option can improve performance at the cost of a risk of data corruption in the event of a system crash. In kernel NFS servers up to and including version 1.0.0, async was the default; but more recent versions use sync as the default.

hide ornohide

Ordinarily or when you use the hide option, the NFS server "hides" filesystems mounted inside an exported directory. For instance, if you export /usr and if /usr/local is a separate partition, clients won't see /usr/local's contents. If you specifynohide, clients will see files and subdirectories in /usr/local. The nohide option can confuse some clients, and works only with single-host specifications (hostnames and IP addresses). Instead of using nohide, you can export each partition individually and mount each export on the NFS clients.

root_squash or no_root_squash

For security reasons, the NFS server normally "squashes" access from root on the client, substituting a low-privilege user ID for the root user ID. You can grant the remote root user full root access to the exported directory by using the no_root_squash option. This option is potentially very dangerous, though.

all_squash orno_all_squash

This option specifies whether or not to apply "squashing" to accesses from ordinary users. Squashing such accesses can be desirable as a

Option

Meaning

means of providing a modest security increase on

read-only exports.

Note The options available in the NFS server have changed between NFS server versions in the past, and they may change in the future. Consult the exports man page for details if you have problems with any of these options.

As an example of an NFS /etc/exports file, consider Listing 24.1. This file defines three exports—for/home, /opt, and /exports. The /home export is fairly straightforward. The clients of this export (collins, gordon, swigert, roosa, and worden) are defined using hostnames without domain names. All of these clients have read/write access to the share. All except gordon must connect from a secure port, but gordon is granted an exception to this rule. Perhaps gordon is running a non-Unix OS that uses a high-numbered port for NFS access. The /opt export is made available to two clients, mattingly.luna.edu and evans.luna.edu. The first of these clients has full read/write access to the share, and root access from this client is not squashed. You might use this configuration if mattingly's administrator needs to be able to add software to the /opt export, but this configuration is risky—a security problem could allow a miscreant to change files in this potentially sensitive directory. Finally, the /exports directory is exported to all computers in the lm.luna.edu domain (but not its subdomains) and to all computers in the 172.24.0.0/16 network. In the case of the lm.luna.edu domain, all user accesses are squashed. In both cases, no client can write to the export.

Listing 24.1: Example /etc/exports File

/home collins(rw) gordon(rw,insecure) swigert(rw) roosa(rw) worden(rw) /opt mattingly.luna.edu(rw,no_root_squash) evans.luna.edu(ro,nohide) /exports *.lm.luna.edu(ro,all_squash) 172.24.0.0/16(ro)

You should keep in mind the fact that NFS relies on its clients to handle some security tasks. In particular, note that NFS doesn't require a password for access. If the client is authorized in /etc/exports, the client can access the directory or directories in question. A couple of decades ago, only professionally administered Unix workstations would have such access, so risks were low. Today, anybody who can fake a DNS entry or gain physical access to a network to hijack an IP address can break into a regular NFS server and read files under any assumed username. For this reason, you should be very conservative about authorizing remote access via the exports file. In some environments, read/write access to home directories may be required, but read/write access to most other directories is most likely an undue risk. Listing 24.1's read/write and no_root_squash access to/optformattingly is particularly risky; I presented it only to give an example of no_root_squash in action.

If you make changes to your /etc/exports file, you can tell the NFS server about those changes with the exportfs program. Specifically, type exportfs -r as root to update the server's list of available exports to match the exports file. You can also use this utility's -u option to make a specific export unavailable, or various other options to have other effects. Consult the exportfs man page for details.

0 0

Post a comment