• Choose a category
• All
• Classic-Fiction

These groups are very different from those in /etc/group. The group file (or equivalent NIS map) explicitly grants permissions to users while the netgroup mechanism simply creates shorthand notations or nicknames. A netgroup can be used in many places where a user or hostname would appear, such as the password file or in the list of hosts that can access an NFS filesystem.

You can also build netgroups from other netgroups. For example, you could create the netgroup hosts-n-users from the following entry:

hosts-n-users trusted-hosts, trusted-users

This netgroup contains all the members of both trusted-hosts and trusted-users.

By using netgroups carefully, you can create special-purpose groups that can be managed separately. For example, you could create a group of "administrators" that can easily be added to the password list of every machine, or a group of "visitors" who are only added to the password files of certain machines.

A final note about netgroups: they are accessible only through NIS. The library routines that have been modified to use NIS maps have also been educated about the uses of the netgroup map, and use the netgroup, password, and host maps together. If NIS is not running, netgroups are not defined. This implies that any netgroup file on an NIS client is ignored, because the NIS netgroup map replaces the local file. A local netgroup file does nothing at all. The uses of netgroups will be revisited as a security mechanism.

Hostname formats in netgroups

The previous section used nonfully qualified hostnames, which are hostnames without a domain name suffix. This is the norm when using the hosts map in NIS to store hostnames. If you have hostnames that are available only in DNS, then you can and must use fully qualified hostnames in the netgroup map if you want those hosts to be members of a particular netgroup. See Chapter 5 for more details on running NIS and DNS on the same network.

Integrating NIS maps with local files

For files that are augmented by NIS maps, you typically strip the local file to the minimum number of entries needed for bootstrap or single-user operation. You then add in entries that are valid only on the local host — for example, a user with an account on only one machine — and then integrate NIS services by adding special entries that refer to the NIS map files.

The /etc/nsswitch.conf file is used to control how NIS maps and local files are integrated. Normally if the two are integrated, the file is interpreted first, followed by the NIS map. For example, look at the passwd entry in the default nsswitch.conf for NIS clients:

passwd: files nis

The keyword files tells the system to read /etc/passwd first, and if the desired entry is not found, search passwd.byname or passwd.byuid, depending on whether the system is searching by account name or user identifier number. The reason why the passwd file is examined before the NIS map is that some accounts, such as root, are not placed in NIS, for security reasons (see Section 3.2.2 in this chapter). If NIS were searched before the local passwd file, and if root were in NIS, then there would effectively be one global password for root. This is not desirable, because once an attacker figured out the root password for one system, he'd know the root password for all systems. Or, even if root were not in NIS, if clients were configured to read NIS before files for passwd information, the attacker that successfully compromised a NIS server, would be able to insert a root entry in the passwd map and gain access to every client.

* * *

Tip

The default files and NIS integration will have your clients getting hostname and address information from NIS. Since you will likely have DNS running, you will find it better to get host informaton from DNS. See Chapter 5.

* * *

At this point, we've run through most of what you need to know to get NIS running. With this background out of the way, we'll look at how NIS works. Along the way, we will give more precise definitions