Managing User Accounts (Running Linux, 4th Edition)

Apart from personal accounts, there are users on the system who provide administrative functions. As we've seen, the system administrator uses the root account to perform maintenance — but usually not for personal system use. Such accounts are accessed using the su command, allowing another account to be accessed after logging in through a personal account.

5.7.1. The passwd File

Every account on the system has an entry in the file /etc/passwd. This file contains entries, one line per user, that specify several attributes for each account, such as the username, real name, and so forth.

Each entry in this file is of the format:

username:password:uid:gid:gecos:homedir:shell

The following list explains each field:

username: A unique character string, identifying the account. For personal accounts, this is the name the user logs in with. On most systems it is limited to eight alphanumeric characters — for example, larry or kirsten.
password: An encrypted representation of the user's password. This field is set using the passwd program to set the account's password; it uses a one-way encryption scheme that is difficult (but not impossible) to break. You don't set this by hand; the passwd program does it for you. Note, however, that if the first character of the passwd field is * (an asterisk), the account is "disabled"; the system will not allow logins as this user. See Section 5.7.5 later in this chapter.
uid: The user ID, a unique integer the system uses to identify the account. The system uses the uid field internally when dealing with process and file permissions; it's easier and more compact to deal with integers than byte strings. Therefore, both the uid and the username identify a particular account: the uid is more important to the system, while username is more convenient for humans.
gid: The group ID, an integer referring to the user's default group, found in the file /etc/group. See Section 5.7.4, later in this chapter.
gecos: Miscellaneous information about the user, such as the user's real name, and optional "location information" such as the user's office address or phone number. Such programs as mail and finger use this information to identify users on the system; we'll talk more about it later. By the way, gecos is a historical name dating back to the 1970s; it stands for General Electric Comprehensive Operating System. GECOS has nothing to do with Unix, except that this field was originally added to /etc/passwd to provide compatibility with some of its services.
homedir: The user's home directory, for his personal use; more on this later. When the user first logs in, her shell finds its current working directory in the named homedir.
shell: The name of the program to run when the user logs in; in most cases, this is the full pathname of a shell, such as /bin/bash or /bin/tcsh.

Many of these fields are optional; the only required fields are username, uid, gid, and homedir. Most user accounts have all fields filled in, but "imaginary" or administrative accounts may use only a few.

Here are two sample entries you might find in /etc/passwd:

root:ZxPsI9ZjiVd9Y:0:0:The root of all evil:/root:/bin/bash
aclark:BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash

The first entry is for the root account. First of all, notice that the uid of root is 0. This is what makes root root: the system knows that uid 0 is "special" and that it does not have the usual security restrictions. The gid of root is also 0, which is mostly a convention. Many of the files on the system are owned by root and the root group, which have a uid and gid of 0, respectively. More on groups in a minute.

On many systems, root uses the home directory /root, or just /. This is not usually relevant because you most often use su to access root from your own account. Also, it is tradition to use a Bourne-shell variant (in this case /bin/bash) for the root account, although you can use the C shell if you like. (Shells are discussed in Section 4.5 in Chapter 4.) Be careful, though: Bourne shells and C shells have differing syntax, and switching between them when using root can be confusing and lead to mistakes.

The second entry is for an actual human being, username aclark. In this case, the uid is 104. The uid field can technically be any unique integer; on many systems, it's customary to have user accounts numbered 100 and above and administrative accounts in the sub-100 range. The gid is 50, which just means that aclark is in whatever group is numbered 50 in the /etc/group file. Hang on to your horses; groups are covered Section 5.7.4 later in this chapter.

Home directories are often found in /home, and named for the username of their owner. This is, for the most part, a useful convention that avoids confusion when finding a particular user's home directory, but you can technically place a home directory anywhere. You should, however, observe the directory layout used on your system.

Note that as the system administrator, it's not usually necessary to modify the /etc/passwd file directly. Several programs are available that can help you create and maintain user accounts; see Section 5.7.5, which follows.

5.7.2. Shadow Passwords

To some extent, it is a security risk to let everybody with access to the system view the encrypted passwords in /etc/passwd. Special crack programs are available that try a huge number of possible passwords and check whether the encrypted version of those passwords is equal to a specified one.

To overcome this potential security risk, shadow passwords have been invented. When shadow passwords are used, the password field in /etc/passwd contains only an x or a *, which can never occur in the encrypted version of a password. Instead, a second file called /etc/shadow is used. This file contains entries that look very similar to those in /etc/passwd, but contain the real encrypted password in the password field. /etc/shadow is readable only by root, so normal users do not have access to the encrypted passwords. The other fields in /etc/shadow, except the username and the password, are present as well, but normally contain bogus values or are empty.

Note that in order to use shadow passwords, you need special versions of the programs that access or modify user information, such as passwd or login. Nowadays, most distributions come with shadow passwords already set up so that this should not be a problem for you. Debian users should use "shadowconfig on" instead to ensure that shadow passwords are enabled on their systems.

There are two tools for converting "normal" user entries to shadow entries and back. pwconv takes the /etc/passwd file, looks for entries that are not yet present in /etc/shadow, generates shadow entries for those, and merges them with the entries already present in /etc/shadow.

pwunconv is rarely used because it gives you less security instead of more. It works like pwconv, but generates traditional /etc/passwd entries that work without /etc/shadow counterparts.

5.7.3. PAM and Other Authentication Methods

You might think that having two means of user authentication, /etc/passwd and /etc/shadow, is already enough choice, but you are wrong in this case. There are a number of other authentication methods with strange names, such as Kerberos authentication (so named after the dog from Greek mythology that guards the entrance to Hell). While we think that shadow passwords provide enough security for almost all cases, it all depends on how much security you really need and how paranoid you want to be.

The problem with all those authentication methods is that you cannot simply switch from one to another because you always need a set of programs, such as login and passwd, that go with those tools. To overcome this problem, the Pluggable Authentication Methods (PAM) system has been invented. Once you have a PAM-enabled set of tools, you can change the authentication method of your system by reconfiguring PAM. The tools will automatically get the code necessary to perform the required authentication procedures from dynamically loaded shared libraries.

Setting up and using PAM is beyond the scope of this book, but you can get all the information you need from http://www.kernel.org/pub/linux/libs/pam/. Most modern distributions will set up PAM for you as well.

5.7.4. The Group File

User groups are a convenient way to logically organize sets of user accounts and allow users to share files within their group or groups. Each file on the system has both a user and a group owner associated with it. Using ls -l, you can see the owner and group for a particular file, as in:

rutabaga% ls -l boiler.tex
-rwxrw-r--   1 mdw      megabozo    10316 Oct  6 20:19 boiler.tex
rutabaga%

This file is owned by the user mdw and belongs to the megabozo group. We can see from the file permissions that mdw has read, write, and execute access to the file; that anyone in the megabozo group has read and write access; and that all other users have read access only.

This doesn't mean that mdw is in the megabozo group; it simply means the file may be accessed, as shown by the permission bits, by anyone in the megabozo group (which may or may not include mdw).

This way files can be shared among groups of users, and permissions can be specified separately for the owner of the file, the group to which the file belongs, and everyone else. An introduction to permissions appears in Section 4.13 in Chapter 4.

Every user is assigned to at least one group, which you specify in the gid field of the /etc/passwd file. However, a user can be a member of multiple groups. The file /etc/group contains a one-line entry for each group on the system, very similar in nature to /etc/passwd. The format of this file is:

groupname:password:gid:members

Here, groupname is a character string identifying the group; it is the group name printed when using commands such as ls -l.

password is an optional encrypted password associated with the group, which allows users not in this group to access the group with the newgrp command. Read on for information on this.

gid is the group ID used by the system to refer to the group; it is the number used in the gid field of /etc/passwd to specify a user's default group.

members is a comma-separated list of usernames (with no whitespace in between), identifying those users who are members of this group, but who have a different gid in /etc/passwd. That is, this list need not contain those users who have this group set as their "default" group in /etc/passwd; it's only for users who are additional members of the group.

For example, /etc/group might contain the following entries:

root:*:0:
bin:*:1:root,daemon
users:*:50:
bozo:*:51:linus,mdw
megabozo:*:52:kibo

The first entries, for the groups root and bin, are administrative groups, similar in nature to the "imaginary" accounts used on the system. Many files are owned by groups, such as root and bin. The other groups are for user accounts. Like user IDs, the group ID values for user groups are often placed in ranges above 50 or 100.

The password field of the group file is something of a curiosity. It isn't used much, but in conjunction with the newgrp program it allows users who aren't members of a particular group to assume that group ID if they have the password. For example, using the command:

rutabaga% newgrp bozo
Password: password for group bozo
rutabaga%

starts a new shell with the group ID of bozo. If the password field is blank, or the first character is an asterisk, you receive a permission denied error if you attempt to newgrp to that group.

However, the password field of the group file is seldom used and is really not necessary. (In fact, most systems don't provide tools to set the password for a group; you could use passwd to set the password for a dummy user with the same name as the group in /etc/passwd and copy the encrypted password field to /etc/group.) Instead, you can make a user a member of multiple groups simply by including the username in the members field for each additional group. In the previous example, the users linus and mdw are members of the bozo group, as well as whatever group they are assigned to in the /etc/passwd file. If we wanted to add linus to the megabozo group as well, we'd change the last line of the previous example to:

megabozo:*:52:kibo,linus

The command groups tells you which groups you belong to, as in:

rutabaga% groups
users bozo

Giving a list of usernames to groups lists the groups to which each user in the list belongs.

When you log in, you are automatically assigned to the group ID given in /etc/passwd, as well as any additional groups for which you're listed in /etc/group. This means you have "group access" to any files on the system with a group ID contained in your list of groups. In this case, the group permission bits (set with chmod g+...) for those files apply to you (unless you're the owner, in which case the owner permission bits apply instead).

Now that you know the ins and outs of groups, how should you assign groups on your system? This is really a matter of style and depends on how your system will be used. For systems with just one or a handful of users, it's easiest to have a single group (called, say, users) to which all personal user accounts belong. Note that all the system groups — those groups contained within /etc/group when the system is first installed — should probably be left alone. Various daemons and programs may depend upon them.

If you have a number of users on your machine, there are several ways to organize groups. For example, an educational institution may have separate groups for students, faculty, and staff. A software company might have different groups for each design team. On other systems, each user is placed into a separate group, named identically to the username. This keeps each pigeon in its own hole, so to speak. Files can also be assigned to special groups; many users create new groups and place files into them for sharing the files between users. However, this requires adding users to the additional groups, a task that usually requires the system administrator to intervene (by editing /etc/group or using utilities, such as gpasswd on Debian systems). It's really up to you.

Another situation in which groups are often used is special hardware groups. Let's say that you have a scanner that is accessed via /dev/scanner. If you do not want to give everybody access to the scanner, you could create a special group called scanner, assign /dev/scanner to this group, make this special file readable for the group and nonreadable for everybody else, and add everybody who is allowed to use the scanner to the scanner group in the /etc/groups file.

5.7.5. Creating Accounts

Creating a user account requires several steps: adding an entry to /etc/passwd, creating the user's home directory, and setting up the user's default configuration files (such as .bashrc) in her home directory. Luckily, you don't have to perform these steps manually; nearly all Linux systems include a program called adduser to do this for you.[16]

[16]Note that some Linux systems, such as Red Hat or SuSE, use a different set of tools for account creation and deletion. If the sequence of inputs in this section does not work for you, check the documentation for your distribution. (Red Hat allows accounts to be managed through the control-panel tool, and SuSE does it via YaST; Debian includes a noninteractive "adduser" script that automatically sets up users based on the configuration file /etc/adduser.conf ). In addition, there are graphical user management programs like kuser from KDE (see Chapter 11).

Running adduser as root should work as follows. Just enter the requested information at the prompts; many of the prompts have reasonable defaults you can select by pressing Enter:

Adding a new user. The username should not exceed 8 characters
in length, or you many run into problems later.

Enter login name for new account (^C to quit): norbert

Editing information for new user [norbert]

Full Name: Norbert Ebersol
GID [100]: 117

Checking for an available UID after 500
First unused uid is 501

UID [501]: (enter)
Home Directory [/home/norbert]: (enter)
Shell [/bin/bash]: (enter)
Password [norbert]: (norbert's password)

Information for new user [norbert]:
Home directory: [/home/norbert] Shell: [/bin/bash]
Password: [(norbert's password)] uid: [501] gid: [117]

Is this correct? [y/N]: y

Adding login [norbert] and making directory [/home/norbert]
Adding the files from the /etc/skel directory:
./.emacs -> /home/norbert/./.emacs
./.kermrc -> /home/norbert/./.kermrc
./.bashrc -> /home/norbert/./.bashrc
... more files ...

There should be no surprises here; just enter the information as requested or choose the defaults. Note that adduser uses 100 as the default group ID, and looks for the first unused user ID after 500 (500 is used as the minimum on SuSE and Red Hat, Debian uses 1000). It should be safe to go along with these defaults; in the previous example we used a group ID of 117 because we designated that to be the group for the user, as well as the default user ID of 501.

After the account is created, the files from /etc/skel are copied to the user's home directory. /etc/skel contains the "skeleton" files for a new account; they are the default configuration files (such as .emacs and .bashrc) for the new user. Feel free to place other files here if your new user accounts should have them.

After this is done, the new account is ready to roll; norbert can log in, using the password set using adduser. To guarantee security, new users should always change their own passwords, using passwd, immediately after logging in for the first time.

root can set the password for any user on the system. For example, the command:

passwd norbert

prompts for a new password for norbert, without asking for the original password. Note, however, that you must know the root password in order to change it. If you forget the root password entirely, you can boot Linux from an "emergency floppy," and clear the password field of the /etc/passwd entry for root. See Section 8.6 in Chapter 8.

Some Linux systems provide the command-line-driven useradd instead of adduser. This program requires you to provide all relevant information as command-line arguments. If you can't locate adduser and are stuck with useradd, see the manual pages, which should help you out.

5.7.6. Deleting and Disabling Accounts

Deleting a user account is much easier than creating one; this is the well-known concept of entropy at work. To delete an account, you must remove the user's entry in /etc/passwd, remove any references to the user in /etc/group, and delete the user's home directory, as well as any additional files created or owned by the user. For example, if the user has an incoming mailbox in /var/spool/mail, it must be deleted as well.

The command userdel (the yin to useradd's yang) deletes an account and the account's home directory. For example:

userdel -r norbert

will remove the recently created account for norbert. The -r option forces the home directory to be removed as well. Other files associated with the user — for example, the incoming mailbox, crontab files, and so forth — must be removed by hand. Usually these are quite insignificant and can be left around. By the end of this chapter, you should know where these files are, if they exist. A simple way to find the files associated with a particular user is through the command:

find / -user username -ls

This will give an ls -l listing of each file owned by username. Of course, to use this, the account associated with username must still have an entry in /etc/passwd. If you deleted the account, use the -uid num argument instead, where num is the numeric user ID of the dearly departed user.

Temporarily (or not-so-temporarily) disabling a user account, for whatever reason, is even simpler. You can either remove the user's entry in /etc/passwd (leaving the home directory and other files intact), or add an asterisk to the first character of the password field of the /etc/passwd entry, as so:

aclark:*BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash

This will disallow logins to the account in question. Note that if you use shadow password, you need to do the same thing in /etc/shadow.

5.7. Managing User Accounts