7.1 Objective 1: Manage Users and Group Accounts

Whether on a corporate server or personal desktop machine, managing user accounts is an important aspect of running a Linux system. The root, or superuser, account is established when you first install Linux. Unlike single-user systems (such as MS-DOS), multiuser systems (such as Linux) require the notion of an owner for files, processes, and other system objects. In many cases, an object's owner is a human system user who created the object. Many objects are also owned by system services, such as web servers. Each of these owners is differentiated from others by a unique user account, which is assigned to it by the system administrator.

If you're building your own desktop system, you may be tempted to use the root account for daily activity, thus avoiding user account issues. In most cases, however, the privileges that come with the superuser account aren't required for much of your daily activity and can be a double-edged sword. It is easy to make big mistakes when you have full privileges across the entire system. Instead, running your daily tasks with a standard user account and reserving the use of the root account for tasks that require those privileges is always safer, even for experts.

7.1.1 User Accounts and the Password File

When a new user account is added to a Linux system, an entry is added to a list of users in the password file, which is stored in /etc/passwd. This file gets its name from its original use, which was to store user information including an encrypted form of the user's password. The password file is in plain text and is readable by everyone on the system. Each line in the password file contains information for a single user account, with item detail separated by colons as illustrated in Figure 7-1.

Figure 7-1. Sample lines from a password file

Each line in the file contains information for a single system account and contains the following pieces of information in colon-separated fields:

Username

The first field on a line is a unique username for the person or service using the account. The username is usually a short form of the person's name, such as jdean.

Password

Each username has an associated password. The password stored in this field is in an encrypted (unreadable) form. Despite the encryption, for security reasons, most systems now store users passwords in a separate /etc/shadow file. If the password is not included, its field is filled by the letter x, which indicates that the shadow password system is in use.

User ID

Each username requires a unique user identifier, or UID. The UID is simply a nonnegative integer. The root account is assigned the UID of 0, which affords it global privilege on the system. Other users have a positive UID, and it is not unusual to begin the sequence for new users at a large number like 100, or on some Linux distributions, 500. By convention, the UID values from to 99 are reserved for administrative use; those over 99 are for regular system users.

Group ID

Each username has a default group identifier, or GID. The GID is also a nonnegative integer. Groups are a way of allowing users to share files through mutual group membership. Group numbers and their associated names are specified in the /etc/group file. The GID stored for each user in /etc/passwd is its default group ID, though a user may belong to many groups.

User's name (or other comment)

The user's name or other information is stored as plain text and usually contains the user's full name. This field may contain spaces.

Home directory

The home directory is the default directory in the filesystem for the account. If a new account is meant for a person, a home directory will probably be created in the filesystem with standard configuration files that the user may then personalize. The full path to that home directory is listed here.

Default shell

This field specifies the default shell for the user or service, which is the shell that runs when the user logs in or opens a shell window. In most cases, the shell will be /bin/bash or /bin/tcsh, but it can be any shell, or even another executable program.^[1]

^[1] Non-shell entries may be seen in the case of some services that should own files but never log in interactively. You may see the shell field filled with /bin/false, a small program that does nothing but yield an error and terminate. This ensures that a service account is secured from login.

In looking back at Figure 7-1, the first line shows the definition of the root account with UID and GID of 0, a name of "root," a home directory of /root, and a default shell of /bin/bash. The second line shows a standard user account for Jeff Dean, with UID and GID of 500. The home directory is /home/jdean and the default shell is /bin/tcsh.

On the Exam You must be prepared to name the fields in the passwd file.

In both cases, note that the password field contains a single letter x. This indicates that the password is stored in /etc/shadow and not /etc/passwd; /etc/shadow is secured and readable only by the root user. This technique reduces the likelihood of an attack against passwords on your system. Shadow passwords and the attacks they defend against are discussed later in this Objective.

7.1.2 Groups and the Group File

In addition to ownership by individual system users, filesystem objects have separate ownership settings for groups of users. This group ownership allows an additional level of user-specific access control beyond that of a file's individual owner. Groups are similar to users in their administration and are defined in the file /etc/group. Like the passwd file, the group file contains colon-separated fields:

Group name

Each group must have a unique name.

Group password

Just as user accounts have passwords, groups can have passwords for their membership. If the password field is empty, the group does not require a password.

Group ID

Each group requires a unique GID. Like a UID, a GID is a nonnegative integer.

Group member list

The last field is a list of group members by username, separated by commas.

Together, these pieces of information define a group; colons separate the fields. Here are a few sample lines from a group file:

root:x:0:root
pppusers:x:230:jdean,jdoe
finance:x:300:jdean,jdoe,bsmith
jdean:x:500:
jdoe:x:501:
bsmith:x:502:

On the Exam Remember that some distributions assign all accounts to the users group while others assign a group for each account. Red Hat Linux, for example, creates single-user groups for all users. In contrast, SuSE Linux assigns the users group (GID 100) as the default for all users.

In this example, both jdean and jdoe are members of the pppusers group (GID 230), and jdean, jdoe, and bsmith are all members of the finance group (GID 300). The remaining groups, root, jdean, jdoe, and bsmith are single-user groups. These groups are not intended for multiple users and do not contain additional members. For security purposes, it is common to create new users with their own personal single-user group. Doing this enhances security because new files and directories will not have group privileges for other users.^[2]

^[2] Although the GID of these single-user groups may match the UID of the user for which they're created, there is no direct relationship between the UID and GID.

7.1.3 The Shadow Password and Shadow Group Systems

At one time, the encryption used on passwords in the world-readable /etc/passwd file was a roadblock to anyone trying to break into a Unix system account. The encrypted passwords were meaningless, and there was no way to reverse-engineer them. However, improved computer performance has led to tools that can process encrypted passwords through what is known as a dictionary attack. In this form of attack, a list of common words and typical passwords is encrypted. The encrypted words are then compared against the publicly available encrypted passwords. If a match is found, the account in question is compromised and can then be used by someone other than its owner.

7.1.3.1 Shadow passwords

Encrypted passwords must be secure from all users on the system, while leaving the remainder of the information in /etc/passwd world-readable. To do this, the encrypted password is moved to a new file that "shadows" the password file line for line. The file is aptly called /etc/shadow and is generally said to contain shadow passwords. Here are a few example lines from a shadow file:

root:$1$oxEaSzzdXZESTGTU:10927:0:99999:7:-1:-1:134538444
jdean:$1$IviLopPn461z47J:10927:0:99999:7::11688:134538412

The first two fields contain the username and the encrypted passwords. The remaining fields contain optional additional information on password aging information.

7.1.3.2 Group passwords and shadow groups

Just as user accounts listed in /etc/passwd are protected by encrypted passwords, groups listed in /etc/group can also be protected by passwords. A group password can be used to allow access to a group by a user account that is not actually a member of the group.^[3] Account users can use the newgrp command to change their default group and enter the group password. If the password is correct, the account is granted the group privileges, just as a group member would be.

^[3] This begs the question "Why not simply make that user a member of the group instead of handing out group passwords?" Indeed, group passwords are rarely used, precisely because group membership is so simple to administer and is more secure than publicly known passwords. It is unlikely that you will need to use group passwords. Nevertheless, understanding group passwords is a requirement for Exam 101.

The group definition file, like the password file, is readable by everyone on the system. If group passwords are stored there, a dictionary attack could be made against them. To protect against such attacks, passwords in /etc/group can be shadowed. The protected passwords are stored in /etc/gshadow, which is readable only by root. Here are a few sample lines from a gshadow file:

root:::root
pppusers:x::
finance:0cf7ipLtpSBGg::
jdean:x::
jdoe:x::
bsmith:x::

In this example, the groups pppusers, jdean, jdoe, and bsmith do not have group passwords as indicated by the x in the password field. The finance group is the only one with a password, which is encrypted.

On the Exam A major contrast between passwd/group and shadow/gshadow is the permissions on the files. The standard files are readable by everyone on the system, but the shadow files are readable only by root, which protects encrypted passwords from theft and possible cracking.

7.1.4 User and Group Management Commands

Although possible, it is rarely necessary (or advised) to manipulate the account and group definition files manually with a text editor. Instead, a family of convenient administrative commands is available for managing accounts, groups, password shadowing, group shadowing, and password aging.^[4]

^[4] Password aging (rules governing change intervals and automated expiration of passwords) is not an explicit Objective for the LPIC Level 1 exams.

Syntax

useradd [options] user

Description

Create the account useron the system. Both system defaults and specified options define how the account is configured. All system account files are updated as required. An initial password must subsequently be set for new users using the passwd command. It is the user's responsibility to go back and change that password when he first logs in to the system.

Frequently used options

-c "comment"

Define the comment field, probably the user's name.

-d homedir

Use homedir as the user's home directory.

-D

List (and optionally change) system default values.

-m

Create and populate the home directory.

-s shell

Use shell as the default for the account.

Examples

Add a new user, bsmith, with all default settings:

# useradd bsmith

Add a new user, jdoe, with a name, default home directory, and the tcsh shell:

# useradd -mc "Jane Doe" -s /bin/tcsh jdoe

Syntax

usermod [options] user

Description

Modify an existing user account. The usermod command accepts many of the same options as useradd does.

Frequently used options

-L

Lock the password, disabling the account.

-U

Unlock the user's password, enabling the user to once again log into the system.

Examples

Change jdoe's name in the comment field:

# usermod -c "Jane Deer-Doe" jdoe

Lock the password for bsmith:

# usermod -L bsmith 

Syntax

userdel [-r] user

Description

Delete an existing user account. When combined with the -r option, the user's home directory is deleted. Note that completely deleting accounts may lead to confusion when files owned by the deleted user remain in other system directories. For this reason, it is common to disable an account rather than delete it. Accounts can be disabled using the chage, usermod, and passwd commands.

Example

Delete the user bsmith, including the home directory:

# userdel -r bsmith 

Syntax

groupadd group

Description

Add groupto the system. In the rare case that a group password is desired on group, it must be added using the gpasswd command after the group is created.

Syntax

groupmod [option] group

Description

Modify the parameters of group.

Option

-n name

Change the name of group to name.

Syntax

groupdel group

Description

Delete group from the system. Deleted groups can lead to the same confusion in the filesystem as described previously for deleting a user (see userdel).

Syntax

passwd [options] username

Description

Interactively set the password for username. The password cannot be entered on the command line.

Option

-l

Available only to the superuser, this option locks the password for the account.

Syntax

gpasswd groupname

Description

Interactively set the group password for groupname. The password cannot be entered on the command line.

7.1.4.1 Additional user and group management commands

While they are not specifically required for this Objective, this discussion would not be complete without a few additional commands for managing users and groups.

Syntax

pwconv

Description

Convert a standard password file to a password and shadow password combination, enabling shadow passwords on the system.

Syntax

pwunconv

Description

Revert from a shadow password configuration to a standard password file.

Syntax

grpconv

Description

Convert a standard group file to a group and shadow group combination, enabling shadow groups on the system. Shadow passwords are rarely necessary.

Syntax

grpunconv

Description

Revert from a shadow group configuration to a standard group file.

Syntax

chage [options] user 

Description

Modify password aging and expiration settings for user. Nonprivileged users may use this command with the -l option for their username only.

Frequently used options

-E expiredate

Set the account to expiration date expiredate in the form MM/DD/YY or MM/DD/YYYY.

-l

List a user's password settings.

Example 1

Display password settings for user jdoe (including nonprivileged user jdoe):

$ chage -l jdoe

Example 2

Set jdoe's account expiration date to January 1, 2002:

# chage -E 01/01/2002 jdoe

On the Exam You must be familiar with these account management commands as well as be ready to specify methods for adding, removing, and modifying user accounts.