5.1 Users and Groups | Practical Unix & Internet Security, 3rd Edition

Although every Unix user has a username consisting of one or more characters , inside the computer Unix represents the identity of each user by a single number: the user identifier (UID). Under most circumstances, each user is assigned his own unique ID.

Unix also uses special usernames for a variety of system functions. As with usernames associated with human users, system usernames usually have their own UIDs as well. Here are some common "users" on various versions of Unix:

root: Superuser account. Performs accounting and low-level system functions.
bin: Binary owner. Has ownership of system files on some systems but doesn't typically execute programs.
daemon: Handles some aspects of the network. This username is also associated with other utility systems, such as the print spoolers, on some versions of Unix.
mail: Handles aspects of electronic mail. On many systems there is no mail user, and daemon is used instead.
guest: Used (infrequently) for site visitors to access the system.
ftp: Used for anonymous FTP access.
uucp: Controls ownership of the Unix serial ports. ( uucp traditionally managed the UUCP system, which is now deprecated.)
news: Used for Usenet news.
lp: Used for the printer system. ^[1]

^[1] lp stands for line printer, although these days most people seem to be using laser printers.
nobody: Owns no files and is sometimes used as a default user for unprivileged operations.
www or http: Runs the web server.
named: Runs the BIND name server.
sshd: Performs unprivileged operations for the OpenSSH Secure Shell daemon.
operator: Used for creating backups and (sometimes) for printer operation.
games: Allowed to access high-score files.
amanda: Used for the Amanda remote backup system.

5.1.1 The /etc/passwd File

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 ^[2] 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.

^[2] Technically, it is a simple relational database.

5.1.2 User Identifiers (UIDs)

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.

There is generally nothing special about any Unix account name. All Unix privileges are determined by the UID (and sometimes the group ID, or GID), and not directly by the account name. Thus, an account with name root and UID 1005 would have no special privileges, but an account named mortimer with UID 0 would be a superuser.

In general, you should avoid creating users with a UID of 0 other than root , and you should avoid using the name root for a regular user account. In this book, we will use the terms "root" and "superuser" interchangeably to mean a 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.

5.1.3 Groups and Group Identifiers (GIDs)

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. ^[3]

^[3] The advantage of assigning each user his own group is that it allows users to have a unified umask of 007 in all instances. When users wish to restrict access of a file or directory to themselves , they leave the group set to their individual group. When they wish to open the file or directory to members of their workgroup or project, all they need to do is to change the file's or directory's group accordingly .

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.

Some special versions of Unix support mandatory access controls (MAC), which have controls based on data labeling instead of, or in addition to, the traditional Unix discretionary access controls (DAC). MAC-based systems do not use traditional Unix groups. Instead, the GID values and the /etc/group file may be used to specify security access control labeling or to point to capability lists. If you are using one of these systems, you should consult the vendor documentation to ascertain what the actual format and use of these values might be.

5.1.3.1 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. ^[4]

^[4] As with the password file, if your site is running NIS, NIS+, or DCE, the /etc/group file may be incomplete or missing. See the discussion in Section 4.3.1 in Chapter 4.

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)
	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. ^[5]

^[5] If you are on a system that uses NIS, NIS+, or some other system for managing user accounts throughout a network, these network databases will be referenced as well. For more information, see Chapter 19.

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.

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.