Managing NFS and NIS, 2nd Edition - Mike Eisler [142]
The triple-based format of the netgroups map clouds the real function of the netgroups. Because all utilities parse either host or usernames, you will find it helpful to define netgroups that contain only host or usernames. It's easier to remember what each group is supposed to do, and the time required to administer a few extra netgroups will be more than made up by time not wasted chasing down strange permission problems that arise from the way the netgroups map is used.
An example here helps to show how the netgroup map can produce unexpected results. We'll build a netgroup containing a list of users and hosts that we trust on a server named gate. Users in the netgroup will be able to log in to gate, and hosts in the netgroup will be able to mount filesystems from it. The netgroup definition looks like this:
gate-group (,stern,), (,johnc,), (bitatron, -,), (corvette, -,)
In the /etc/dfs/dfstab file on gate, we'll add a host access restriction:
share -o rw=gate-group /export/home/gate
No at-sign (@) is needed to include the netgroup name in the /etc/dfs/dfstab file. The netgroup map is searched first for the names in the rw= list, followed by the hosts map.
In /etc/hosts.equiv on gate, we'll include the gate-group netgroup:
+ +@gate-group
To test our access controls, we go to a machine not in the netgroup — NFS client vacation — and attempt to mount /export/home/gate. We expect that the mount will fail with a "Permission denied" error:
vacation# mount gate:/home/gate/home/gate
/mnt
vacation#
The mount completes without any errors. Why doesn't this netgroup work as expected?
The answer is in the wildcards left in the host fields in the netgroup entries for users stern and johnc. Because a wildcard was used in the host field of the netgroup, all hosts in the NIS map became part of gate-group and were added to the access list for /export/home/gate. When creating this netgroup, our intention was probably to allow users stern and johnc to log in to gate from any host on the network, but instead we gave away access rights.
A better way to manage this problem is to define two netgroups, one for the users and one for the hosts, so that wildcards in one definition do not have strange effects on the other. The modified /etc/netgroup file looks like this:
gate-users: (,stern,), (,johnc,)
gate-hosts: (bitatron,,), (corvette,,)
In the /etc/dfs/dfstab file on gate, we use the gate-hosts netgroup:
share -o rw=gate-hosts /export/home/gate
and in /etc/hosts.equiv, we use the netgroup gate-users. When host information is used, the gate-hosts group explicitly defines those hosts in the group; when usernames are needed, the gate-users map lists just those users. Even though there are wildcards in each group, those wildcards are in fields that are not referenced when the maps are used in these function-specific ways.
How secure are NIS and NFS?
NFS and NIS have bad reputations for security. NFS earned its reputation because of its default RPC security flavor AUTH_SYS (see Section 12.4.1 later in this chapter) is very weak. There are better security flavors available for NFS on Solaris and other systems. However, the better security flavors are not available for all, or even most NFS implementations, resulting in a practical dilemma for you. The stronger the NFS security you insist on, the more homogenous your computing environment will become. Assuming that secure file access across the network is a requirement, another option to consider is to not run NFS and switch to another file access system. Today there are but two practical choices:
SMB (also known as CIFS)
This limits your desktop environment to Windows. However, as discussed in Section 10.2.1, if you want strong security, you'll have to