Managing NFS and NIS, 2nd Edition - Mike Eisler [61]
root=client_list
Grants superuser access to the NFS clients identified in client_list. The form of client_list is the same as that described for the rw=client_list option. To enforce basic network security, by default, superuser privileges are not extended over the network. The root option allows you to selectively grant root access to a filesystem. This security feature will be covered in Section 12.4.2.
sec=mode[:mode ...]
Requires that NFS clients use the security mode(s) specified. Security modes can be:
sys
This is the default form of security, which assumes a trusted relationship between NFS clients and servers.
dh
This is a stronger form of security based on a cryptographic algorithm known as Diffie-Hellman Key Exchange.
krb5
krb5i
krb5p
This is a trio of stronger forms of security based on a key management system called Kerberos Version 5.
none
This is the weakest form of security. All users are treated as unknown and are mapped to the anonymous user.
The sec= option can be combined with rw, ro, rw=, ro=, and root= in interesting ways. We will look at that and other security modes in more detail in Section 12.4.4.
aclok
ACL stands for Access Control List. The aclok option can sometimes prevent interoperability problems involving NFS Version 2 clients that do not understand Access Control Lists. We will explore ACLs and the aclokoption in Section 12.4.8.
nosub
nosuid
Under some situations, the nosub and nosuid options prevent security exposures. We will go into more detail in Chapter 12.
public
This option is useful for environments that have to cope with firewalls. We will discuss it in more detail also in Chapter 12 .
Your system may support additional options, so check your vendor's relevant manual pages.
Mounting filesystems
This section uses filenames and command names specific to Solaris. Note that you are better off using the automounter (see Chapter 9) to mount filesystems, rather than using the mount utility described in this section. However, understanding the automounter, and why it is better than mount, requires understanding mount. Thus, we will discuss the concept of NFS filesystem mounting in the context of mount.
Solaris has different component names from non-Solaris systems. Table 6-3 shows the rough equivalents to non-Solaris systems.
Table 6-3. Correspondence of Solaris and non-Solaris mount components
Description
Solaris
Non-Solaris
List of filesystems
/etc/vfstab
/etc/fstab
List of mounted filesystems
/etc/mnttab
/etc/mtab
RPC program number to network address mapper
(portmapper)
rpcbind
portmap
MOUNT daemon
mountd
rpc.mountd
NFS clients can mount any filesystem, or part of a filesystem, that has been exported from an NFS server. The filesystem can be listed in the client's /etc/vfstab file, or it can be mounted explicitly using the mount(1M) command. (Also, in Solaris, see the mount_nfs(1M) manpage, which explains NFS-specific details of filesystem mounting.)
NFS filesystems appear to be "normal" filesystems on the client, which means that they can be mounted on any directory on the client. It's possible to mount an NFS filesystem over all or part of another filesystem, since the directories used as mount points appear the same no matter where they actually reside. When you mount a filesystem on top of another one, you obscure whatever is "under" the mount point. NFS clients see the most recent view of the filesystem. These potentially confusing issues will be the foundation for the discussion of NFS naming schemes later in this chapter.
Using /etc/vfstab
Adding entries to /etc/vfstab is one way to mount NFS filesystems. Once the entry has been added to the vfstab file, the client mounts it on every reboot. There are several features that distinguish NFS filesystems in the vfstab file:
The "device name"