Managing NFS and NIS, 2nd Edition - Mike Eisler [149]
The anonymous user mapping is valid only for the filesystem that is exported with the anon option. It is possible to set up different mappings for each filesystem exported by specifying a different anonymous user ID value in each line of the /etc/dfs/dfstab file:
share -o rw,anon=100 /export/home/engin
share -o rw,anon=200 /export/home/admin
share -o rw,anon=300 /export/home/marketing
Anonymous users should almost never be mapped to root, as this would grant superuser access to filesystems to any user without a valid password file entry on the server. An exception would be when you are exporting read-only, and the data is not sensitive. One application of this is exporting directories containing the operating system installation. Since operating systems like Solaris are often installed over the network, and superuser on the client drives the installation, it would be tedious to list every possible client that you want to install the operating system on.
Anonymous users should be thought of as transient or even unwanted users, and should be given as few file access permissions as possible. RPC calls with missing UIDs in the credential structures are rejected out of hand on the server if the server exports its filesystems with anon=-1. Rather than mapping anonymous users to nobody, filesystems that specify anon=-1 return authentication errors for RPC calls with no credentials in them.
Normally, with the anonymous user mapped to nobody, anonymous requests are accepted but have few, if any, permissions to access files on the server. Mapping unknown users is a risky venture. Requests that are missing UIDs in their credentials may be appearing from outside the local network, or they may originate from machines on which security has been compromised. Thus, if you must export filesystems with the anonymous user mapped to a UID other than nobody, you should limit it to a smaller set of hosts:
share -o rw=engineering,anon=100 /export/home/engin # a nergroup
share -o rw=admin1:admin2,anon=200 /export/home/admin # a pair of hosts
share -o rw=.marketing.widget.com,anon=300 /export/home/marketing # a domain
We discuss limiting exports to certain hosts in the next section.
Access to filesystems
In addition to being protected from root access, some filesystems require protection from certain hosts. A machine containing source code is a good example; the source code may be made available only to a selected set of machines and not to the network at large. The list of hosts to which access is restricted is included in the server's /etc/dfs/dfstab file with the rw= option:
share -o rw=noreast,root=noreast /export/root/noreast
This specification is typical of that for the root filesystem of a diskless client. The client machine is given root access to the filesystem, and access is further restricted to host noreast only. No user can look at noreast 's root filesystem unless he or she can log into noreast and look locally. The hosts listed in a rw= list can be individual hostnames or netgroup names, separated by colons. On Solaris 8, the hosts can also be DNS domain names, if prefixed by a leading dot (.), or a network number if preceded by a leading at sign (@). Solaris 8 also has the capability to deny specific hosts (individual hostnames, netgroups, domains, or network numbers) access. For example:
share -o rw=-marketing /source
Restricting host access ensures that NFS is not used to circumvent login restrictions. If a user cannot log into a host to restrict access to one or more filesystems, the user should not be able to recreate that host's environment by mounting all of its NFS-mounted filesystems on another system.
Read-only access
By default, NFS filesystems are exported with write access enabled for any host that mounts them. Using the ro or ro= option in the /etc/dfs/dfstab file, you can specify whether the filesystem is exported read-only, and to what hosts:
share -o ro=system-engineering /source