The mount_nfs(1M) and share_nfs(1M) commands each provide a way to specify the security mode to be used on an NFS file system through the sec=mode option. mode can be sys, dh, krb5, krb5i, krb5p, or none. These security modes can also be added to the automount maps. mount_nfs(1M) allows you to specify a single security mode; share_nfs(1M) allows you to specify multiple modes (or none). With multiple modes, an NFS client can choose any of the modes in the list.
The sec=mode option on the share_nfs(1M) command line establishes the security mode of NFS servers. If the NFS connection uses the NFS Version 3 protocol, the NFS clients must query the server for the appropriate mode to use. If the NFS connection uses the NFS Version 2 protocol, then the NFS client uses the default security mode, which is currently sys. NFS clients may force the use of a specific security mode by specifying the sec=mode option on the command line. However, if the file system on the server is not shared with that security mode, the client may be denied access.
If the NFS client wants to authenticate the NFS server using a particular (stronger) security mode, the client wants to specify the security mode to be used, even if the connection uses the NFS Version 3 protocol. This guarantees that an attacker masquerading as the server does not compromise the client.
The NFS security modes are described below. Of these, the krb5, krb5i, krb5p modes use the Kerberos V5 protocol for authenticating and protecting the shared filesystems. Before these can be used, the system must be configured to be part of a Kerberos realm. See kerberos(5).
Use AUTH_SYS authentication. The user's UNIX user-id and group-ids are passed in the clear on the network, unauthenticated by the NFS server. This is the simplest security method and requires no additional administration. It is the default used by Solaris NFS Version 2 clients and Solaris NFS servers.
Use a Diffie-Hellman public key system (AUTH_DES, which is referred to as AUTH_DH in RFC 2695: Authentication Mechanisms for ONC RPC.
Use Kerberos V5 protocol to authenticate users before granting access to the shared filesystem.
Use Kerberos V5 authentication with integrity checking (checksums) to verify that the data has not been tampered with.
User Kerberos V5 authentication, integrity checksums, and privacy protection (encryption) on the shared filesystem. This provides the most secure filesystem sharing, as all traffic is encrypted. It should be noted that performance might suffer on some systems when using krb5p , depending on the computational intensity of the encryption algorithm and the amount of data being transferred.
Use null authentication (AUTH_NONE). NFS clients using AUTH_NONE have no identity and are mapped to the anonymous user nobody by NFS servers. A client using a security mode other than the one with which a Solaris NFS server shares the file system has its security mode mapped to AUTH_NONE. In this case, if the file system is shared with sec=none, users from the client are mapped to the anonymous user. The NFS security mode none is supported by share_nfs(1M).
Sharing uses one or more of the specified security modes. The mode in the sec=mode option must be a node name supported on the client. If the sec= option is not specified, the default security mode used is AUTH_SYS. Multiple sec= options can be specified on the command line, although each mode can appear only once.
Each sec= option specifies modes that apply to any subsequent window=, rw, ro, rw=, ro= and root= options that are provided before another sec=option. Each additional sec= resets the security mode context, so that more window=, rw, ro, rw=, ro= and root= options can be supplied for additional modes.
The NFSv4 server constructs a shared file system name space which is identical to the real file system name space on the server, including directories which are not actually shared, if they lead to shared directories. The constructed parts of the name space are known as the pseudo-fs. The pseudo-fs is always read-only.
As with NFSv3, the security mode of the shared directory is controlled using the sec=mode option of share_nfs(1M). However, the security mode of pseudo-fs objects is the union of the various security modes of the shared directories below.
When an NFSv4 client performs a mount, the client traverses the server's name space, from the root, down to the directory being mounted. Using the features of the NFSv4 protocol, the client may negotiate the security flavor of the directories as it proceeds down. If no sec= mode option is given to mount_nfs or an automounter map entry, then the client will do full negotiation for each directory down to the mount point, changing security flavors as needed. If sec=mode option is given, the client is constrained to use the requested security mode for all operations.
The following example shares /var with Kerberos authentication and integrity protection:
share -F nfs -o sec=krb5i /varExample 2 Sharing /var with Kerberos Authentication and Privacy Protection
The following example shares/var with Kerberos authentication and privacy protection:
share -F nfs -o sec=krb5p /varExample 3 Sharing /var with Kerberos Authentication and Optionally Falling Back to AUTH_SYS Authentication
The following example shares /var with Kerberos authentication and optionally falls back to AUTH_SYS authentication:
share -F nfs -o sec=krb5:sys /varExample 4 Sharing /var with Kerberos Authentication Allowing read/write Operations for Kerberos Authenticated Users and Optionally Falling Back to AUTH_SYS Authentication Allowing only Read Operations
The following example shares /var with Kerberos authentication allowing read/write operations for Kerberos authenticated users and optionally falls back to AUTH_SYS authentication allowing only read operations:
share -F nfs -o sec=krb5,rw,sec=sys,ro /var
NFS security service configuration file
See attributes(5) for descriptions of the following attributes:
RFC 2695: Authentication Mechanisms for ONC RPC
/etc/nfssec.conf lists the NFS security services. Do not edit this file. It is not intended to be user-configurable. See kclient(1M) .