On most Unix systems the user accounts are listed in the database file /etc/passwd; the corresponding passwords for these accounts are kept in a file named /etc/shadow, /etc/security/passwd, or /etc/master.passwd. To improve lookup speed, some systems compile the password file into a compact index file named something like /etc/pwd.db, which is used instead.

Here is an example of an /etc/passwd file from a Linux system containing a variety of system and ordinary users:

$ more /etc/passwd
root:x:0:0:Mr. Root:/root:/bin/bash
bin:x:1:1:Binary Installation User:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/dev/null
rpm:x:37:37::/var/lib/rpm:/bin/bash
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
ntp:x:38:38::/etc/ntp:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/bin/false
gdm:x:42:42::/var/gdm:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/bin/false
ident:x:98:98:pident user:/:/sbin/nologin
rachel:x:181:181:Rachel Cohen:/u/rachel:/bin/ksh
ralph:x:182:182:Ralph Knox:/u/ralph:/bin/tcsh
mortimer:x:183:183:Mortimer Merkle:/u/mortimer:/bin/sh

Notice that most of these accounts do not have “people names,” and that all have a password field of “x”. In the old days of Unix, the second field was used to hold the user’s encrypted password. This information is now stored in a second file, the shadow password file.

The /etc/passwd file can be thought of as a directory^[50] that lists all of the users on the system. As we saw in the last chapter, it is possible to configure a Unix system to use other directory services, such as NIS, NIS+, LDAP, and Kerberos. (We’ll discuss directory services in detail in Chapter 14.) When these systems are used, the Unix operating system is often modified so that the utility programs still respond as if all of the accounts actually reside in a single /etc/passwd file.

UIDs are historically unsigned 16-bit integers, which means they can range from 0 to 65535. UIDs between 0 and 99 are typically used for system functions; UIDs for humans usually begin at 100 or 1000. Many versions of Unix now support 32-bit UIDs. A few older versions of Unix have UIDs that are signed 16-bit integers, ranging from -32768 to 32767.

There is one special UID, which is UID 0. This is the UID that is reserved for the Unix superuser. The Unix kernel disables most security checks when a process is being run by a user with the UID of 0.

Unix keeps the mapping between usernames and UIDs in the file /etc/passwd. Each user’s UID is stored in the field after the one containing the user’s encrypted password. For example, consider the sample /etc/passwd entry presented in Chapter 4:

rachel:x:181:181:Rachel Cohen:/u/rachel:/bin/ksh

In this example, Rachel’s username is rachel and her UID is 181.

The UID is the actual information that the operating system uses to identify the user; usernames are provided merely as a convenience for humans. If two users are assigned the same UID, Unix views them as the same user, even if they have different usernames and passwords. Two users with the same UID can freely read and delete each other’s files and can kill each other’s running programs. Giving two users the same UID is almost always a bad idea; it is better to create multiple users and put them in the same group, as we will see later.

Conversely, files can be owned by a UID that is not listed in /etc/passwd as having an associated username. This is also a bad idea. If a user is added to /etc/passwd in the future with that UID, that user will suddenly become the owner of the files.

Every Unix user belongs to one or more groups. As with user accounts, groups have both a group name and a group identification number (GID). GID values are also historically 16-bit integers, but many systems now use 32-bit integers for these, too.

As the name implies, Unix groups are used to group users together. As with usernames, group names and numbers are assigned by the system administrator when each user’s account is created. Groups can be used by the system administrator to designate sets of users who are allowed to read, write, and/or execute specific files, directories, or devices.

Each user belongs to a primary group that is stored in the /etc/passwd file. The GID of the user’s primary group follows the user’s UID. Historically, every Unix user was placed in the group users, which had a GID of 100. These days, however, most Unix sites place each account in its own group. This results in decreased sharing but somewhat greater security.^[51]

Consider, again, our /etc/passwd example:

rachel:x:181:181:Rachel Cohen:/u/rachel:/bin/ksh

In this example, Rachel’s primary GID is 181.

Groups provide a handy mechanism for treating a number of users in a certain way. For example, you might want to set up a group for a team of students working on a project so that students in the group, but nobody else, can read and modify the team’s files.

Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, many Unix computers are set up so that only users who belong to the kmem group can examine the operating system’s kernel memory. The operator group is commonly used to allow only specific users to run the tape backup system, which may have “read” access to the system’s raw disk devices. And a sources group might be limited to people who have signed nondisclosure forms so they can view the source code for particular software.

The /etc/group file

The /etc/group file contains the database that lists every group on your computer and its corresponding GID. Its format is similar to the format used by the /etc/passwd file.^[52]

Here is a sample /etc/group file that defines six groups: wheel, http, vision, startrek, rachel, and users:

wheel:*:0:root,rachel
http:*:10:http
users:*:100:
vision:*:101:keith,arlin,janice
startrek:*:102:janice,karen,arlin
rachel:*:181:

The first line of this file defines the wheel group. The fields are explained in Table 5-1.

Table 5-1. The first line of the example /etc/group file

Field contents	Description
wheel	Group name
*	Group’s “password” (described later)
0	Group’s GID
root, rachel	List of the users who are in the group

Most versions of Unix use the wheel group as the list of all of the computer’s system administrators (in this case, rachel and the root user are the only members). On some systems, the group has a GID of 0; on other systems, the group has a GID of 10. Unlike a UID of 0, a GID of 0 is usually not significant. However, the name wheel is very significant: on many systems the use of the su command to invoke superuser privileges is restricted to users who are members of a group named wheel.

The second line of this file defines the http group. There is one member in the http group—the http user.

The third line defines the users group. The users group does not explicitly list any users; on some systems, each user is placed into this group by default through his individual entry in the /etc/passwd file.

The fourth and fifth lines define two groups of users. The vision group includes the users keith, arlin, and janice. The startrek group contains the users janice, karen, and arlin. Notice that the order in which the usernames are listed on each line is not important. (This group is depicted graphically in Figure 5-1.)

Finally, the sixth line defines a group for the user rachel.

Remember that the users mentioned in the /etc/group file are in these groups in addition to the groups mentioned as their primary groups in the file /etc/passwd. For example, Rachel is in the rachel group even though she does not appear in that group in the file /etc/group because her primary group number is 181. On most versions of Unix, you can use the groups command to list which groups that you are currently in:

% groups
rachel wheel
%

The groups command can also take a username as an argument:

% groups arlin
vision, startrek
%

When a user logs into the Unix system, the /bin/login program scans the /etc/passwd and /etc/group files, determines which groups the user is a member of, and adds them to the user’s user structure using the setgroups( ) system call.^[53]

Some versions of Unix are equipped with an id command that offers more detailed UIDs, GIDs, and group lists:

% id
uid=181(rachel) gid=181(rachel) groups=181(rachel), 0(wheel)
% id root
uid=0(root) gid=0(wheel) groups=0(wheel),1(bin),15(shadow),65534(nogroup)

Figure 5-1 illustrates how users can be included in multiple groups.

Figure 5-1. Users and groups

Group Passwords

The newgrp command is used to change the user’s active group. This is useful when a user wants to create files owned by a group other than his default group.

$ id
uid=1001(alansz) gid=20(users)
$ newgrp project
$ id
uid=1001(alansz) gid=100(project)

Solaris and other versions of Unix derived from AT&T SVR4 allow users to use newgrp to switch to a group that they are not a member of if the group is equipped with a group password:

$ newgrp fiction
password: rates34
$

The user is now free to exercise all of the rights and privileges of the fiction group instead of his default group.

The password in the /etc/group file is interpreted exactly like the passwords in the /etc/passwd file, including salts (described in Chapter 4 and Chapter 19). However, most systems do not have a program to install or change the passwords in this file. To set a group password, you must first assign it to a user with the passwd command, then use a text editor to copy the encrypted password out of the /etc/passwd file into the /etc/group file. Alternatively, you can encode the password using the /usr/lib/makekey program (if present) and edit the result into the /etc/group file in the appropriate place.

Group passwords are rarely used and can represent a security vulnerability, as an attacker can put a password on a critical group as a way of creating a back door for future access.

Tip

It is not necessary for there to be an entry in the /etc/group file for a group to exist! As with UIDs and account names, Unix actually uses only the integer part of the GID for all settings and permissions. The name in the /etc/group file is simply a convenience for the users—a means of associating a mnemonic with the GID value.