Section 11.1. Managing User Accounts

Even if you're the only actual human being who uses your Linux system, understanding how to manage user accounts is importanteven more so if your system hosts multiple users.

User accounts serve a number of purposes on Unix systems. Most prominently, they give the system a way to distinguish between different people who use the system for reasons of identification and security. Each user has a personal account with a separate username and password. As discussed in "File Ownership and Permissions," later in this chapter, users may set permissions on their files, allowing or restricting access to them by other users. Each file on the system is "owned" by a particular user, who may set the permissions for that file. User accounts are used to authenticate access to the system; only those people with accounts may access the machine. Also, accounts are used to identify users, keep system logs, tag electronic mail messages with the name of the sender, and so forth.

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 maintenancebut 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.

Other accounts on the system may not involve human interaction at all. These accounts are generally used by system daemons , which must access files on the system through a specific user ID other than root or one of the personal user accounts. For example, if you configure your system to receive a newsfeed from another site, the news daemon must store news articles in a spool directory that anyone can access but only one user (the news daemon) can write to. No human being is associated with the news account; it is an "imaginary" user set aside for the news daemon only.

One of the permission bits that can be set on executables is the setuid bit, which causes the program to be executed with the permissions of the owner of that file. For example, if the news daemon were owned by the user news, and the setuid bit were set on the executable, it would run as if by the user news. news would have write access to the news spool directory, and all other users would have read access to the articles stored there. This is a security feature. News programs can give users just the right amount of access to the news spool directory, but no one can just play around there.

As the system administrator, it is your job to create and manage accounts for all users (real and virtual) on your machine. This is actually a painless, hands-off task in most cases, but it's important to understand how it works.

11.1.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 following 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 charactersfor 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 password field is * (an asterisk), the account is "disabled"; the system will not allow logins as this user. See "Creating Accounts," 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 user ID and the username identify a particular account: the user ID is more important to the system, whereas the 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 "The Group File," 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 the user's personal use; more on this later. When the user first logs in, the shell finds its current working directory in the named home directory.
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 user ID 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 traditional 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 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 hats; groups are covered in "The Group File," 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. You can technically place a home directory anywhere, but it must exist for you to be able to log into the system. 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 "Creating Accounts," later in this chapter. If you really want to edit the raw /etc/passwd data, consider using a command such as vipw that protects the password file against corruption from simultaneous editing.

11.1.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 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.

Modern Linux systems also provide something called password aging. This is sort of an expiry date for a password; if it approaches, a warning is issued, a configurable number of days before the password expires, and the user is asked to change his password. If he fails to do so, his account will be locked after a while. It is also possible to set a minimum number of days before a changed or created password can be changed again.

All these settings are configured with the passwd command. The -n option sets the minimum number of days between changes, -x the maximum number of days between changes, -w the number of days a warning is issued before a password expires, and -i the number of days of inactivity between the expiry of a password and the time the account is locked.

Most distributions provide graphical tools to change these settings, often hidden on an Advanced Settings page or similar.

11.1.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. 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). Although 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.

11.1.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 the following example:

    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 "File Ownership and Permissions," later in this chapter.

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:

    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 groupsthose groups contained within /etc/group when the system is first installedshould 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 might 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.

11.1.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. 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 yast2; Debian includes an adduser script (interactive in some versions and noninteractive on others) that automatically sets up users based on the configuration file /etc/adduser.conf). In addition, there are graphical user management programs, such as KUser from KDE and the GNOME System Tools.

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 disk (as discussed previously), and clear the password field of the /etc/passwd entry for root. See "What to Do in an Emergency" in Chapter 27.

Some Linux systems provide the command-line-driven useradd instead of adduser. (And, to make things even more confusing, on some other systems, the two commands are synonyms.) 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.

11.1.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 userfor example, the incoming mailbox, crontab files, and so forthmust 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 following 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 follows:

    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 passwords, you need to do the same thing in /etc/shadow. But why would you want to do that? Well, imagine that an employee is leaving the company, and you want to prevent him from logging in any more, but you still want to keep his files around in case there is anything his colleagues still need. In this case, it is convenient to be able to disable the account without actually deleting the home directory (and other related files such as the mail spool).

11.1.7. Modifying User Accounts

Modifying attributes of user accounts and groups is usually a simple matter of editing /etc/passwd and /etc/group. Many systems provide commands such as usermod and groupmod to do just this; it's often easier to edit the files by hand.

To change a user's password, use the passwd command, which will prompt for a password, encrypt it, and store the encrypted password in the /etc/passwd file.

If you need to change the user ID of an existing account, you can do this by editing the uid field of /etc/passwd directly. However, you should also chown the files owned by the user to that of the new user ID. For example:

    chown -R aclark /home/aclark

will set the ownership for all files in the home directory used by aclark back to aclark, if you changed the uid for this account. If ls -l prints a numeric user ID, instead of a username, this means there is no username associated with the uid owning the files. Use chown to fix this.