NOTES
If the
sec= option is presented at least once, all uses of the
window=,
rw,
ro,
rw=,
ro=, and
root= options must come after the first
sec= option. If the
sec= option is not presented, then
sec=
sys is implied.
If one or more explicit
sec= options are presented,
sys must appear in one of the options mode lists for accessing using the AUTH_SYS security mode to be allowed. For example:
share -F nfs /var
share -F nfs -o sec=sys /var
grants read-write access to any host using AUTH_SYS, but
share -F nfs -o sec=dh /var
grants no access to clients that use AUTH_SYS.
Unlike previous implementations of
share_nfs, access checking for the
window=,
rw,
ro,
rw=, and
ro= options is done per NFS request, instead of per mount request.
Combining multiple security modes can be a security hole in situations where the
ro= and
rw= options are used to control access to weaker security modes. In this example,
share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
an intruder can forge the IP address for “hosta” (albeit on each NFS request) to side-step the stronger controls of AUTH_DES. Something like:
share -F nfs -o sec=dh,rw,sec=sys,ro /var
is safer, because any client (intruder or legitimate) that avoids AUTH_DES only gets read-only access. In general, multiple security modes per share command should only be used in situations where the clients using more secure modes get stronger access than clients using less secure modes.
If
rw= and
ro= options are specified in the same
sec= clause, and a client is in both lists, the order of the two options determines the access the client gets. If client “hosta” is in two netgroups, “group1” and “group2”, in this example, the client would get read-only access:
share -F nfs -o ro=group1,rw=group2 /var
In this example “hosta” would get read-write access:
share -F nfs -o rw=group2,ro=group1 /var
If within a
sec= clause, both the
ro and
rw= options are specified, for compatibility, the order of the options rule is not enforced. All hosts would get read-only access, with the exception to those in the read-write list. Likewise, if the
ro= and
rw options are specified, all hosts get read-write access with the exceptions of those in the read-only list.
The
ro= and
rw= options are guaranteed to work over UDP and TCP but may not work over other transport providers.
The
root= option with AUTH_SYS is guaranteed to work over UDP and TCP but may not work over other transport providers.
The
root= option with AUTH_DES is guaranteed to work over any transport provider.
There are no interactions between the
root= option and the
rw,
ro,
rw=, and
ro= options. Putting a host in the root list does not override the semantics of the other options. The access the host gets is the same as when the
root= option is absent. For example, the following share command denies access to “hostb”:
share -F nfs -o ro=hosta,root=hostb /var
The following gives read-only permissions to “hostb”:
share -F nfs -o ro=hostb,root=hostb /var
The following gives read-write permissions to “hostb”:
share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
If the file system being shared is a symbolic link to a valid pathname, the canonical path (the path which the symbolic link follows) is shared. For example, if
/export/foo is a symbolic link to
/export/bar, the following share command results in
/export/bar as the shared pathname (and not
/export/foo):
share -F nfs /export/foo
An NFS mount of
server:/export/foo results in
server:/export/bar really being mounted.
This line in the
/etc/dfs/dfstab file shares the
/disk file system read-only at boot time:
share -F nfs -o ro /disk
The same command entered from the command line does not share the
/disk file system unless there is at least one file system entry in the
/etc/dfs/dfstab file. The
mountd(1M) and
nfsd(1M) daemons only run if there is a file system entry in
/etc/dfs/dfstab when starting or rebooting the system.
The
mountd(1M) process allows the processing of a path name the contains a symbolic link. This allows the processing of paths that are not themselves explicitly shared with
share_nfs. For example,
/export/foo might be a symbolic link that refers to
/export/bar which has been specifically shared. When the client mounts
/export/foo the mountd processing follows the symbolic link and responds with the
/export/bar. The NFS Version 4 protocol does not use the mountd processing and the client's use of
/export/foo does not work as it does with NFS Version 2 and Version 3 and the client receives an error when attempting to mount
/export/foo.