share_nfs.1m (2010 09)

s
share_nfs(1M) share_nfs(1M)
APPLICATION USAGE
If the
async option is used, an unreported data loss may occur ONLY on a write and ONLY if the NFS
server experiences a failure after the write reply has been sent to the client. Specifically, blocks which
have been queued for the server’s disk, but have not yet been written to the disk may be lost.
You cannot export either a parent directory or a subdirectory of an exported directory that resides within
the same file system . It is not allowed, for instance, to export both
/usr and /usr/local if both direc-
tories reside on the same disk partition.
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
will grant read-write access to any host using
AUTH_SYS, but
share -F nfs -o sec=dh /var
will grant no access to clients that use AUTH_SYS.
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 will only get 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 tran-
sport 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= options is absent. For example, the following share command will deny access
to hostb:
share -F nfs -o ro=hosta,root=hostb /var
The following will give read-only permissions to hostb:
4 Hewlett-Packard Company − 4 − HP-UX 11i Version 3: September 2010