Chapter 6. User and Group Management

The following topics are covered in this chapter:

• Different User Types

• Creating and Managing User Accounts

• Creating and Managing Group Accounts

The following RHCSA exam objectives are covered in this chapter:

• Create, delete, and modify local user accounts

• Change passwords and adjust password aging for local user accounts

• Create, delete, and modify local groups and group memberships

• Configure superuser access

On a Linux system, a wide variety of processes are normally being used. These processes need access to specific resources on the Linux system. To determine how these resources can be accessed, a difference is made between processes that run in kernel mode and processes that run without full permissions to the operating system. In the latter case user accounts are needed, not only to grant the required permissions to processes, but also to make sure that people can do their work. This chapter explains how to set up user and group accounts.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 6-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and ‘Review Questions.’”

1. Which statement about privileged users (root) is true?

a. A privileged user is a user who has access to a Linux system.

b. A privileged user with no access permissions can do nothing at all.

c. Privileged users are not restricted in any way.

d. On every server, at least one privileged user must be manually created while installing the server.

2. On a default installation of an RHEL 8 server, which group does the user typically need to be a member of to be able to use sudo to run all administration commands?

a. admin

b. root

c. sys

d. wheel

3. There are different ways that users can run tasks with root permissions. Which of the following is not one of them?

a. sudo

b. runas

c. su

d. PolicyKit

4. Which of the following is used to store the hash of the user’s encrypted password?

a. /etc/passwd

b. /etc/shadow

c. /etc/users

d. /etc/secure

5. Which configuration file should you change to set the default location for all new user home directories?

a. /etc/login.defaults

b. /etc/login.defs

c. /etc/default/useradd

d. /etc/default/login.defs

6. Which command enables you to get information about password properties such as password expiry?

a. chage -l

b. usermod --show

c. passwd -l

d. chage --show

7. Which of the following files is not processed when a user starts a login shell?

a. /etc/profile

b. /etc/.profile

c. ~/.bashrc

d. ~/.bash_profile

8. Which utility can be used to edit group membership directly through the appropriate configuration file?

a. vigr

b. vipw

c. vipasswd

d. usermod

9. Which command can be used to list all groups a user is member of?

a. userlist

b. grouplist

c. id

d. groups

10. What can you do to ensure that no users, except for the user root, can log in temporarily?

a. Set the default shell to /usr/sbin/nologin

b. Set the default shell to /bin/false

c. Create a file with the name /etc/nologin

d. Create a file with the name /etc/nologin.txt

Foundation Topics

Different User Types

In this chapter, you learn how to create and manage user accounts. Before diving into the details of user management, you learn how users are used in a Linux environment.

Users on Linux

On Linux, there are two ways to look at system security. There are privileged users, and there are unprivileged users. The default privileged user is root. This user account has full access to everything on a Linux server and is allowed to work in system space without restrictions. The root user account is meant to perform system administration tasks and should be used for that only. For all other tasks, an unprivileged user account should be used.

To get information about a user account, you can use the id command. When using this command from the command line, you can see details about the current user. You can also use it on other user accounts to get details about those accounts. Example 6-1 shows an example of the output of the command.

[root@localhost ~]# id linda
uid=1001(linda) gid=1001(linda) groups=1001(linda)

Working as Root

On all Linux systems, by default there is the user root, also known as the superuser. This account is used for managing Linux and has no restrictions at all. Root, for instance, can create other user accounts on the system. For some tasks, root privileges are required. Some examples are installing software, managing users, and creating partitions on disk devices. Generally speaking, all tasks that involve direct access to devices need root permissions.

Because the root account is so useful for managing a Linux environment, some people make a habit of logging in as root directly. That is not recommended, especially not when you are logging in to a graphical environment. When you log in as root in a graphical environment, all tasks that are executed run as root as well, and that involves an unnecessary security risk. Therefore, you should instead use one of the following alternative methods. Table 6-2 provides an overview of these methods.

Using su

From a terminal window, you can use the su command to start a subshell in which you have another identity. To perform administrative tasks, for instance, you can log in with a normal user account and type su to open a root shell. This brings the benefit that root privileges are used only in the root shell.

If you type just the command su, the username root is implied. But su can be used to run tasks as another user as well. Type su linda to open a subshell as the user linda, for example. When using su as an ordinary user, you are prompted for a password, and after entering that, you acquire the credentials of the target user:

Click here to view code image

[linda@localhost ~]$ su
Password:
[root@localhost linda]#

The subshell that is started when using su is an environment where you are able to work as the target user account, but environment settings for that user account have not been set. If you need complete access to the entire environment of the target user account, you can use su - to start a login shell. If you start a login shell, all scripts that make up the user environment are processed, which makes you work in an environment that is exactly the same as when logging in as that user.

sudo

If a non-root user needs to perform a specific system administration task, the user does not need root access; instead, the system administrator can configure sudo to give that user administrator permissions to perform the specific task. The user then carries out the task by starting the command with sudo (and entering their password when prompted). So, instead of using commands like useradd as the root user, you can use an ordinary user account and type sudo useradd. This is definitely more secure because you will only be able to act as if you have administrator permissions while running this specific command.

When creating a Linux user during the installation process, you can select to grant administrator permissions to that specific user. If you select to do so, the user will be able to use all administrator commands using sudo. It is also possible to set up sudo privileges after installation by making the user a member of the group wheel. To do that in a very easy way, use this simple two-step procedure:

1. Make the administrative user account a member of the group wheel by using usermod -aG wheel user.

2. Type visudo and make sure the line %wheel ALL=(ALL) ALL is included.

Apart from this method, which would give a user access to all administrative commands, you can use visudo to edit the sudoers configuration file and give user access to specific commands only. For example, if you would include the line linda ALL=/usr/bin/useradd, /usr/bin/passwd in this file, that would allow user linda to run only the commands useradd and passwd with administrative privileges.

PolicyKit

Most administration programs with a graphical user interface use PolicyKit to authenticate as the root user. If a normal user who is not a member of the group wheel accesses such an application, he will be prompted for authentication. If a user who is a member of the group wheel opens a PolicyKit application, he will have to enter his own password. For the RHCSA exam, you do not have to know the details of PolicyKit. If you are interested, you can take a look at the man pages of the pkexec and polkit commands for more details.

In Exercise 6-1, you practice switching user accounts.

Managing User Accounts

Now that you know how to perform tasks as an administrative or nonadministrative user, it is time to learn how to manage user accounts on Linux. In this section, you learn what is involved.

System Accounts and Normal Accounts

A typical Linux environment has two kinds of user accounts. There are normal user accounts for the people who need to work on a server and who need limited access to the resources on that server. These user accounts typically have a password that is used for authenticating the user to the system. There are also system accounts that are used by the services the server is offering. Both types of user accounts share common properties, which are kept in the files /etc/passwd and /etc/shadow. Example 6-2 shows a part of the contents of the /etc/passwd file.

ntp:x:38:38::/etc/ntp:/sbin/nologin
chrony:x:994:993::/var/lib/chrony:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
pulse:x:171:171:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin
gdm:x:42:42::/var/lib/gdm:/sbin/nologin
gnome-initial-setup:x:993:991::/run/gnome-initial-setup/:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
user:x:1000:1000:user:/home/user:/bin/bash

As you can see in Example 6-2, to define a user account, different fields are used in /etc/passwd. The fields are separated from each other by a colon. The following is a summary of these fields, followed by a short description of their purpose.

• Username: This is a unique name for the user. Usernames are important to match a user to her password, which is stored separately in /etc/shadow (see next bullet). On Linux, there can be no spaces in the username, and in general it’s a good idea to specify usernames in all lowercase letters.

• Password: In the old days, the second field of /etc/passwd was used to store the hashed password of the user. Because the /etc/passwd file is readable by all users, this poses a security threat, and for that reason on current Linux systems the hashed passwords are stored in /etc/shadow (discussed in the next section).

• UID: Each user has a unique user ID (UID). This is a numeric ID. It is the UID that really determines what a user can do. When permissions are set for a user, the UID (and not the username) is stored in the file metadata. UID 0 is reserved for root, the unrestricted user account. The lower UIDs (typically up to 999) are used for system accounts, and the higher UIDs (from 1000 on by default) are reserved for people who need to connect a directory to the server. The range of UIDs that are used to create regular user accounts is set in /etc/login.defs.

• GID: On Linux, each user is a member of at least one group. This group is referred to as the primary group, and this group plays a central role in permissions management, as discussed later in this chapter. Users can be a member of additional groups, which are administered in the file /etc/groups.

• Comment field: The Comment field, as you can guess, is used to add comments for user accounts. This field is optional, but it can be used to describe what a user account is created for. Some utilities, such as the obsolete finger utility, can be used to get information from this field. The field is also referred to as the GECOS field, which stands for General Electric Comprehensive Operating System and had a specific purpose for identifying jobs in the early 1970s when General Electric was still an important manufacturer of servers.

• Directory: This is the initial directory where the user is placed after logging in, also referred to as the home directory. If the user account is used by a person, this is where the person would store his personal files and programs. For a system user account, this is the environment where the service can store files it needs while operating.

• Shell: This is the program that is started after the user has successfully connected to a server. For most users this will be /bin/bash, the default Linux shell. For system user accounts, it will typically be a shell like /sbin/nologin. The /sbin/nologin command is a specific command that silently denies access to users (to ensure that if by accident an intruder logs in to the server, he cannot get any shell access). Optionally, you can create an /etc/nologin.txt file, in which case only root will be able to log in but other users will see the contents of this file when their logins are denied.

A part of the user properties is stored in /etc/passwd, which was just discussed. Another part of the configuration of user properties is stored in the /etc/shadow file. The settings in this file are used to set properties of the password. Only the user root and processes running as root have access to /etc/shadow. Example 6-3 shows an example of /etc/shadow contents.

[root@localhost ~]# tail -n 10 /etc/shadow
ntp:!!:16420::::::
chrony:!!:16420::::::
abrt:!!:16420::::::
pulse:!!:16420::::::
gdm:!!:16420::::::
gnome-initial-setup:!!:16420::::::
postfix:!!:16420::::::
sshd:!!:16420::::::
tcpdump:!!:16420::::::
user:$6$3VZbGx1djo6FfyZo$/Trg7Q.3foIsIFYxBm6UnHuxxBrxQxHDnDuZxgS.
  We/MAuHn8HboBZzpaMD8gfm.fmlB/ML9LnuaT7CbwVXx31:16420:0:99999:7:::

The following fields are included in /etc/shadow:

• Login name: Notice that /etc/shadow does not contain any UIDs, but usernames only. This opens a possibility for multiple users using the same UID but different passwords (which, by the way, is not recommended).

• Encrypted password: This field contains all that is needed to store the password in a secure way. If the field is empty, no password is set and the user cannot log in. If the field starts with an exclamation mark, login for this account currently is disabled.

• Days since Jan. 1, 1970, that the password was last changed: Many things on Linux refer to this date, which on Linux is considered the beginning of time. It is also referred to as epoch.

• Days before password may be changed: This allows system administrators to use a more strict password policy, where it is not possible to change back to the original password immediately after a password has been changed. Typically this field is set to the value 0.

• Days after which password must be changed: This field contains the maximal validity period of passwords. Notice in the last line of Example 6-3 that it is set to 99,999 (about 274 years), which is the default.

• Days before password is to expire that user is warned: This field is used to warn a user when a forced password change is upcoming. Notice in the last line of Example 6-3 that it is set to 7 days, which is the default (even if the password validity is set to 99,999 days).

• Days after password expires that account is disabled: Use this field to enforce a password change. After password expiry, the user no longer can log in. After the account has reached the maximum validity period, the account is locked out. This field allows for a grace period in which the user can change their password, but only during the login process. This field is set in days and is unset by default.

• Days since Jan. 1, 1970, that account is disabled: An administrator can set this field to disable an account on a specific date. This is typically a better approach than removing an account, as all associated properties and files of the account will be kept, but the account no longer can be used to authenticate on your server. Note that this field does not have a default value.

• A reserved field, which was once added “for future use”: This field was reserved a long time ago; it will probably never be used.

Most of the password properties can be managed with the passwd or chage command, which are discussed later in this chapter.

Creating Users

There are many solutions for creating users on a Linux server. To start, you can edit the contents of the /etc/passwd and /etc/shadow configuration files directly in an editor, using the vipw command (with the risk of making an error that could make logging in impossible to anyone). Another option is to use useradd, which is the utility that you should use for creating users. To remove users, you can use the userdel command. Use userdel -r to remove a user and the complete user environment.

Modifying the Configuration Files

Creating a user account by modifying the configuration files simply requires adding one line to /etc/passwd and another line to /etc/shadow, in which the user account and all of its properties are defined. This method of creating users is not recommended, though. If you make an error, you might mess up the consistency of the file and make logging in completely impossible to anyone. Also, you might encounter locking problems if one administrator is trying to modify the file contents directly while another administrator wants to write a modification with some tool.

If you insist on modifying the configuration files directly, you should use vipw. This command opens an editor interface on your configuration files, and more important, it sets the appropriate locks on the configuration files to prevent corruption. It does not check syntax, however, so make sure that you know what you are doing, because making even one typo might still severely mess up your server. If you want to use this tool to modify the /etc/shadow file, use vipw -s. To edit the contents of the /etc/group file where groups are defined, a similar command with the name vigr exists.

Using useradd

The useradd utility is probably the most common tool on Linux for managing users. It allows you to add a user account from the command line by using many of its parameters. Use, for instance, the command useradd -m -u 1201 -G sales,ops linda to create a user linda who is a member of the secondary groups sales and ops with UID 1201 and add a home directory to the user account as well. (Secondary groups are explained in the section “Understanding Linux Groups,” later in the chapter.)

Home Directories

All normal users will have a home directory. For people, the home directory is the directory where personal files can be stored. For system accounts, the home directory often contains the working environment for the service account.

As an administrator, you normally will not change home directory–related settings for system accounts because they are created automatically from the RPM post-installation scripts when installing the related software packages. If you have people who need user accounts, you probably do want to manage home directory contents a bit.

When creating home directories (which happens by default while creating users), the content of the “skeleton” directory is copied to the user home directory. The skeleton directory is /etc/skel, and it contains files that are copied to the user home directory at the moment this directory is created. These files will also get the appropriate permissions to ensure that the new user can use and access them.

By default, the skeleton directory contains mostly configuration files that determine how the user environment is set up. If in your environment specific files need to be present in the home directories of all users, you take care of that by adding the files to the skeleton directory.

Managing User Properties

For changing user properties, the same rules apply as for creating user accounts. You can either work directly in the configuration files using vipw or use command-line tools.

The ultimate command-line utility for modifying user properties is usermod. It can be used to set all properties of users as stored in /etc/passwd and /etc/shadow, plus some additional tasks, such as managing group membership. There is just one task it does not do well: setting passwords. Although usermod has an option -p that tells you to “use encrypted password for the new password,” it expects you to do the password encryption before adding the user account. That does not make it particularly useful. If as root you want to change the user password, you’d use the passwd command.

Configuration Files for User Management Defaults

When working with tools such as useradd, some default values are assumed. These default values are set in two configuration files: /etc/login.defs and /etc/default/useradd. Example 6-4 shows the contents of /etc/default/useradd.

[root@localhost skel]# cat /etc/default/useradd
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

As shown in Example 6-4, the /etc/default/useradd file contains some default values that are applied when using useradd.

In the file /etc/login.defs, different login-related variables are set. This file is used by different commands, and it relates to setting up the appropriate environment for new users. Here is a list of some of the most significant properties that can be set from /etc/login.defs:

• MOTD_FILE: Defines the file that is used as the “message of the day” file. In this file, you can include messages to be displayed after the user has successfully logged in to the server.

• ENV_PATH: Defines the $PATH variable, a list of directories that should be searched for executable files after logging in.

• PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE: Define the default password expiration properties when creating new users.

• UID_MIN: The first UID to use when creating new users.

• CREATE_HOME: Indicates whether or not to create a home directory for new users.

Managing Password Properties

You learned about the password properties that can be set in /etc/shadow. You can use two commands to change these properties for users: chage and passwd. The commands are rather straightforward, as long as you know what the options are used for. For instance, the command passwd -n 30 -w 3 -x 90 linda sets the password for user linda to a minimal usage period of 30 days and an expiry after 90 days, where a warning is generated 3 days before expiry.

Many of the tasks that can be accomplished with passwd can be done with chage also. For instance, use chage -E 2020-12-31 bob to have the account for user bob expire on December 31, 2020. To see current password management settings, use chage -l (see Example 6-5). The chage command also has an interactive mode; if you type chage anna, for instance, the command will prompt for all the password properties you want to set interactively.

linux:~ # chage -l linda
Last password change                                : Apr 11, 2019
Password expires                                    : never
Password inactive                                   : never
Account expires                                     : never
Minimum number of days between password change      : 0
Maximum number of days between password change      : 99999
Number of days of warning before password expir     : 7

Creating a User Environment

When a user logs in, an environment is created. The environment consists of some variables that determine how the user is working. One such variable, for instance, is $PATH, which defines a list of directories that should be searched when a user types a command.

To construct the user environment, a few files play a role:

• /etc/profile: Used for default settings for all users when starting a login shell

• /etc/bashrc: Used to define defaults for all users when starting a subshell

• ~/.profile: Specific settings for one user applied when starting a login shell

• ~/.bashrc: Specific settings for one user applied when starting a subshell

When logging in, the files are read in this order, and variables and other settings that are defined in these files are applied. If a variable or setting occurs in more than one file, the last one wins.

In Exercise 6-2, you apply common solutions to create user accounts.

Creating and Managing Group Accounts

Every Linux user has to be a member of at least one group. In this section, you learn how to manage settings for Linux group accounts.

Understanding Linux Groups

Linux users can be a member of two different kinds of groups. First, there is the primary group. Every user must be a member of the primary group, and there is only one primary group. When creating files, the primary group becomes group owner of these files. (File ownership is discussed in detail in Chapter 7, “Permissions Management.”) Users can also access all files their primary group has access to.

The user’s primary group membership is defined in /etc/passwd; the group itself is stored in the /etc/group configuration file.

Besides the mandatory primary group, users can be a member of one or more secondary groups as well. A user can be a member of a secondary group in addition to the primary group. Secondary groups are important to get access to files. If the group a user is a member of has access to specific files, the user will get access to those files also. Working with secondary groups is important, in particular in environments where Linux is used as a file server to allow people working for different departments to share files with one another. You have also seen how secondary group membership can be used to enable user administrative privileges through sudo, by making the user a member of the group wheel.

Creating Groups

As is the case for creating users, there are also different options for creating groups. The group configuration files can be modified directly using vigr or the command-line utility groupadd.

Creating Groups with vigr

With the vigr command, you open an editor interface directly on the /etc/group configuration file. In this file, groups are defined in four fields per group (see Example 6-6).

kvm:x:36:qemu
qemu:x:107:
libstoragemgmt:x:994:
rpc:x:32:
rpcuser:x:29:
"/etc/group.edit" 65L, 870C

The following fields are used in /etc/group:

• Group name: As is suggested by the name of the field, this contains the name of the group.

• Group password: Where applicable, this field contains a group password, a feature that is hardly used anymore. A group password can be used by users who want to join the group on a temporary basis, so that access to files the group has access to is allowed. If a group password is used, it is stored in the /etc/gshadow file, as that file is root accessible only.

• Group ID: This field contains a unique numeric group identification number.

• Members: Here you find the names of users who are a member of this group as a secondary group. Note that this field does not show users who are a member of this group as their primary group.

As mentioned, in addition to /etc/group, there is the /etc/gshadow file. This file is not commonly used to store group passwords (because hardly anyone still uses them), but it does have a cool feature. In the third field of this file you can list administrators. This is a comma-separated list of users that can change passwords for group members, which are listed in the fourth field of this file. Note that specifying group members here is optional, but if it is done, the group member names must be the same as the group members in /etc/group.

Using groupadd to Create Groups

Another method to create new groups is by using the groupadd command. This command is easy to use. Just use groupadd followed by the name of the group you want to add. There are some advanced options; the only significant one is -g, which allows you to specify a group ID when creating the group.

Managing Group Properties

To manage group properties, groupmod is available. You can use this command to change the name or group ID of the group, but it does not allow you to add group members. To do this, you use usermod. As discussed before, usermod -aG will add users to new groups that will be used as their secondary group. Because a group does not have many properties, it is quite common that group properties are managed directly in the /etc/group file by using the vigr command.

In Exercise 6-3, you create two groups and add some users as members to these groups.

Summary

In this chapter, you learned how to create users and groups. You learned which configuration files are used to store users and groups, and you learned which properties are used in these files. You also learned which utilities are available to manage user and group accounts.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix B; Chapter 26, “Final Preparation”; and the practice exams.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 6-3 lists a reference of these key topics and the page number on which each is found.

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

user

password

GECOS

group

primary group

secondary group

privileged user

unprivileged user

root

Review Questions

The questions that follow are meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.

1. What is the UID of user root?

2. What is the configuration file in which sudo is defined?

3. Which command should you use to modify a sudo configuration?

4. Which two files can be used to define settings that will be used when creating users?

5. How many groups can you create in /etc/passwd?

6. If you want to grant a user access to all admin commands through sudo, which group should you make that user a member of?

7. Which command should you use to modify the /etc/group file manually?

8. Which two commands can you use to change user password information?

9. What is the name of the file where user passwords are stored?

10. What is the name of the file where group accounts are stored?

End-of-Chapter Lab

You have now learned how to set up an environment where user accounts can log in to your server and access resources on your server. In this end-of-chapter lab, you learn how to configure an environment for users and groups.

Lab 6.1

Set up a shared group environment that meets the following requirements:

• Create two groups: sales and account.

• Create users bob, betty, bill, and beatrix. Make sure they have their primary group set to a private group that has the name of the user.

• Make bob and betty members of the group sales, and bill and beatrix members of the group account.

• Set a password policy that requires users to change their password every 90 days.