•  Objective 2.2 Given a scenario, manage users and groups.

If you want to buy a famous and expensive piece of art, you should make sure it isn’t a fake. In other words, you would want to make sure it is authentic. The same is true for allowing users access to a computer system. You want to make sure they are authentic users who have been previously given authorization to access the system. This process is called authentication and is formerly defined as determining if a person or program is who they claim to be. This chapter covers administering the access controls Linux uses to check a user’s credentials and permit or deny access to the system.

Besides user authentication, you need to know how to audit users, manage group memberships, configure user environments, and, if needed, set up disk space usage limits for the accounts.

Managing User Accounts

Adding and modifying user account credentials, which includes usernames, account information, and passwords, is an important (but tedious) part of system administration. In addition, you need to know how to delete these credentials, when warranted. Managing user accounts and looking at the underlying credential framework is covered in the following sections.

Adding Accounts

To add a new user account on the system, the useradd utility is typically used. However, the process actually involves several players besides the useradd command. A depiction of the process is illustrated in Figure 10.1.

You can see in Figure 10.1 that there are several team players involved in the account creation process. Notice that the /etc/skel directory is bolded. This is because, depending upon the other configuration files, it may not be used in the process. The same goes for the /home/userid directory. It may not be created or it may have an alternative name, depending upon the system’s account creation configuration. You’ll learn more about these directories shortly.

Before we jump into the useradd utility details, let’s look at the two files and the directory involved in the creation side of the process.

The /etc/login.defs File

This configuration file is typically installed by default on most Linux distributions. It contains directives for use in various shadow password suite commands. Shadow password suite is an umbrella term for commands dealing with account credentials, such as the useradd, userdel, and passwd commands.

The directives in this configuration file control password length, how long until the user is required to change the account’s password, whether or not a home directory is created by default, and so on. The file is typically filled with comments and commented-out directives (which make the directives inactive). Listing 10.1 shows only the active directives within the /etc/login.defs file, after stripping out blank and comment lines on a Fedora Workstation distribution.

Listing 10.1: Active directives in the /etc/login.defs configuration file

$ grep -v ^$ /etc/login.defs | grep -v ^#
MAIL_DIR        /var/spool/mail
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7
UID_MIN                  1000
UID_MAX                 60000
SYS_UID_MIN               201
SYS_UID_MAX               999
GID_MIN                  1000
GID_MAX                 60000
SYS_GID_MIN               201
SYS_GID_MAX               999
CREATE_HOME     yes
UMASK           077
USERGROUPS_ENAB yes
ENCRYPT_METHOD SHA512
$

Notice the UID_MIN directive within Listing 10.1. A User Identification Number (UID) is the number used by Linux to identify user accounts. A user account, sometimes called a normal account, is any account an authorized human has been given to access the system, with the appropriate credentials, and perform daily tasks. While humans use account names, Linux uses UIDs. The UID_MIN indicates the lowest UID allowed for user accounts. On the system in Listing 10.1, UID_MIN is set to 1000. This is typical, though some systems set it at 500.

System accounts are accounts that provide services (daemons) or perform special tasks, such as the root user account. A system account’s minimum UID is set by the SYS_UID_MIN, and its maximum is set by the SYS_UID_MAX directive. The settings in this file are typical.

Just keep in mind that these settings are for accounts created after the initial Linux distribution installation. For example, the root user account always has a UID of 0, which is below the SYS_UID_MIN as shown snipped in Listing 10.2.

Listing 10.2: The root user account’s UID

$ gawk -F: '{print $3, $1}' /etc/passwd | sort -n
0 root
1 bin
2 daemon
3 adm
[…]

Some additional directives critical to common user account creation are covered briefly in Table 10.1.

Name	Description
PASS_MAX_DAYS	Number of days until a password change is required. This is the password’s expiration date.
PASS_MIN_DAYS	Number of days after a password is changed until the password may be changed again.
PASS_MIN_LENGTH	Minimum number of characters required in password.
PASS_WARN_AGE	Number of days a warning is issued to the user prior to a password’s expiration.
CREATE_HOME	Default is no. If set to yes, a user account home directory is created.
ENCRYPT_METHOD	The method used to hash account passwords.

The /etc/login.defs file is only one of the configuration files used for the user account process’s creation side. The other file is covered next.

The /etc/default/useradd File

The /etc/default/useradd file is another configuration file that directs the process of creating accounts. It typically is a much shorter file than the /etc/login.defs file. An example from a Fedora Workstation distribution is shown in Listing 10.3

Listing 10.3: The /etc/default/useradd configuration file

$ cat /etc/default/useradd
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
$
$ useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
$

Notice in Listing 10.3 that there are two different ways to display the active directives in this file. You can use the cat command or invoke the useradd -D command. Both are equally simple to use. One cool fact about the useradd -D command is that you can use it to modify the directives within the /etc/default/useradd file.

In Listing 10.3, notice the HOME directive. It is currently set to /home, which means that any newly created user accounts will have their account directories located within the /home directory. Keep in mind that if CREATE_HOME is not set or set to no within the /etc/login.defs file, a home directory is not created by default.

Some additional directives critical to common user account creation are covered briefly in Table 10.2.

Name	Description
HOME	Base directory for user account directories.
INACTIVE	Number of days after a password has expired and has not been changed until the account will be deactivated. See PASS_MAX_DAYS in Table 10.1.
SKEL	The skeleton directory.
SHELL	User account default shell program.

The SHELL directive needs a little more explanation. Typically it is set to /bin/bash, which means when you access the command line, your user process is running the /bin/bash shell program. This program provides you with the prompt at the command line and handles any commands you enter there.

 Be aware that some distributions, such as Ubuntu, set the SHELL directive by default to /bin/sh, which is a symbolic link to another shell. On Ubuntu this links to the Dash shell instead of the Bash shell.

The /etc/skel/ Directory

The /etc/skel directory, or the skeleton directory (see Table 10.2) as it is commonly called, holds files. If a home directory is created for a user, these files are to be copied to the user account’s home directory, when the account is created. Listing 10.4 shows the files within the /etc/skel directory on a Fedora Workstation distribution.

Listing 10.4: Files in the /etc/skel directory

$ ls -a /etc/skel
.  ..  .bash_logout  .bash_profile  .bashrc  .mozilla
$

In Listing 10.4, the ls command was employed with the -a option so that hidden files (files starting with a dot) are displayed. Recall that hidden files do not normally display without the -a option on the ls command. These files are account environment files as well as a Mozilla Firefox web browser configuration file directory. We’ll cover environment files later in this chapter. You can modify any of these files or add new files and directories, if needed.

 The /etc/skel files are copied to user account home directories only when the account is created. Therefore, if you make changes to the files later, you’ll have to migrate those changed files to current user accounts either by hand or by shell scripts.

Now that we’ve covered the files in the creation side of the user account creation process, let’s look at the files and directories that are built or modified as part of the process. Go back and look at Figure 10.1, if necessary, to refresh your memory of the various file and directory names.

The /etc/passwd File

Account information is stored in the /etc/passwd file. Each account’s data occupies a single line in the file. When an account is created, a new record for that account is added to the /etc/passwd file. A snipped example is shown in Listing 10.5.

Listing 10.5: Account records in the /etc/passwd file

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
[…]
tcpdump:x:72:72::/:/sbin/nologin
user1:x:1000:1000:User One:/home/user1:/bin/bash
Christine:x:1001:1001:Christine B:/home/Christine:/bin/bash
[…]
$

The /etc/passwd records contain several fields. Each field in a record is delimited by a colon (:). There are seven fields in total, described in Table 10.3.

Field No.	Description
1	User account’s username.
2	Password field. Typically this file is no longer used to store passwords. An x in this field indicates passwords are stored in the /etc/shadow file.
3	User account’s user identification number (UID).
4	User account’s group identification number (GID)
5	Comment field. This field is optional. Traditionally it contains the user’s full name.
6	User account’s home directory.
7	User account’s default shell. If set to /sbin/nologin or /bin/false, then the user cannot interactively log into the system.

You would think that the password file would hold passwords, but due to its file permissions, the password file can be compromised. Therefore, passwords are stored in the more locked-down /etc/shadow file.

 You may find yourself working for an organization that has passwords stored in the /etc/passwd file. If so, politely suggest that the passwords be migrated to the /etc/shadow file via the pwconv command. If the organization refuses, walk, or even better run, to the door and go find a job at a different company.

You may have noticed that in a /etc/password record, field #7 may contain either the /sbin/nologin or /bin/false default shell. This is to prevent an account from interactively logging into the system. The /sbin/nologin is typically set for system service account records. System services (daemons) do need to have system accounts, but they do not interactively log in. Instead, they run in the background under their own account name. If a malicious person attempted to interactively log in using the account (and they made it past other blockades, which you’ll learn about shortly), they are politely kicked off the system. Basically, /sbin/nologin displays a brief message and logs you off, before you reach a command prompt. If desired, you can modify the message shown by creating the file /etc/nologin.txt and add the desired text.

The /bin/false shell is a little more brutal. If this is set as a user account’s default shell, there are no messages shown, and the user is just logged out of the system.

The /etc/shadow File

Another file that is updated when an account is created is the /etc/shadow file. It contains information regarding the account’s password, even if you have not yet provided a password for the account. Like the /etc/passwd file, each account’s data occupies a single file line. A snipped example is shown in Listing 10.6.

Listing 10.6: Account records in the /etc/shadow file

$ sudo cat /etc/shadow
root:!::0:99999:7:::
bin:*:17589:0:99999:7:::
daemon:*:17589:0:99999:7:::
[…]
user1:$6$bvqdqU[…]:17738:0:99999:7:::
Christine:Wb8I8Iw$6[…]:17751:0:99999:7:::
[…]
$

The /etc/shadow records contain several fields. Each field in a record is delimited by a colon (:). There are nine fields in total, described in Table 10.4.

Field No.	Description
1	User account’s username.
2	Password field. The password is a salted and hashed password. A !! or ! indicates a password has not been set for the account. A ! or * indicates the account cannot use a password to log in. A ! in front of a password indicates the account has been locked.
3	Date of last password change in Unix Epoch time (days) format.
4	Number of days after a password is changed until the password may be changed again.
5	Number of days until a password change is required. This is the password’s expiration date.
6	Number of days a warning is issued to the user prior to a password’s expiration. (See field #5).
7	Number of days after a password has expired (see field #5) and has not been changed until the account will be deactivated.
8	Date of account’s expiration in Unix Epoch time (days) format.
9	Called the special flag. It is a field for a special future use, is currently not used, and is blank.

Notice that field #1 is the account’s username. This is the only field shared with the /etc/passwd file.

 Unix Epoch time, which is also called POSIX time, is the number of seconds since January 1, 1970, although the /etc/shadow file expresses it in days. It has a long history with Unix and Linux systems and will potentially cause problems in the year 2038. You don’t have to drag out your calculator to determine what a field’s date is using the Epoch. Instead, the chage utility, covered later in this chapter, does that for you.

It’s vital to understand the different possible expirations. When password expiration has occurred, there is a grace period. The user will have a certain number of days (designated in field #7) to log into the account using the old password but must change the password immediately. However, if password expiration has occurred and the user does not log in to the system in time, the user is effectively locked out of the system.

With account expiration, there is no grace period. After the account expires, the user cannot log into the account with its password.

You may have noticed that we have not yet covered the /etc/group file. It does get modified as part of the account creation process. However, that discussion is saved for the section “Managing Groups” later in this chapter.

The Account Creation Process

Distributions tend to vary greatly in their configuration when it comes to user accounts. Therefore, before you launch into creating accounts with the useradd utility, it’s wise to review some directives within each distro’s user account configuration files (see Tables 10.1 and 10.2). In Listing 10.7, the CREATE_HOME and SHELL directives are checked on a Fedora Workstation distribution.

Listing 10.7: Checking user account directives on Fedora Workstation

$ grep CREATE_HOME /etc/login.defs
CREATE_HOME     yes
$
$ useradd -D | grep SHELL
SHELL=/bin/bash
$

You can see on this Fedora distribution that the home directory will be created by default, because CREATE_HOME is set to yes. The SHELL directive is pointing to the Bash shell, /bin/bash, which is the typical shell for most interactive user accounts.

The useradd command, as mentioned earlier, is the primary tool for creating user accounts on most distributions. Creating an account on a Fedora Workstation distribution with the useradd utility is shown in Listing 10.8.

Listing 10.8: Creating a user account on Fedora Workstation

$ sudo useradd DAdams
[sudo] password for Christine:
$
$ grep ^DAdams /etc/passwd
DAdams:x:1002:1002::/home/DAdams:/bin/bash
$
$ sudo grep ^DAdams /etc/shadow
DAdams:!!:17806:0:99999:7:::
$
$ sudo ls -a /home/DAdams/
.  ..  .bash_logout  .bash_profile  .bashrc  .mozilla
$

Because the Fedora Workstation distribution we are using in Listing 10.8 has the CREATE_HOME directive set to yes and SHELL set to /bin/bash, there is no need to employ any useradd command options. The only argument needed is the user account name, which is DAdams. After the utility is used to create the account in Listing 10.8, notice that records now exist for the new user account in both the /etc/passwd and /etc/shadow files. Also, a new directory was created, /home/DAdams, which contains files from the /etc/skel/ directory. Keep in mind at this point that no password has been added to the DAdams account yet, and thus its record in the /etc/shadow file shows !! in the password field.

Now let’s take a look at creating an account on a different Linux distribution. The Ubuntu Desktop distro does things a little differently. In Listing 10.9, you can see that CREATE_HOME is not set, so it will default to no.

Listing 10.9: Checking user account directives on Ubuntu Desktop

$ grep CREATE_HOME /etc/login.defs
$
$ useradd -D | grep SHELL
SHELL=/bin/sh
$

Also in Listing 10.9, notice that the SHELL directive is set to /bin/sh instead of the Bash shell. This means that when you create an interactive user account, you will need to specify Bash shell, if desired.

Therefore, when creating a user account on this Ubuntu distribution, if you want the account to have a home directory and use the Bash shell, you will need to employ additional useradd command options. The useradd utility has many useful options for various needs and the most typical ones are listed in Table 10.5.

Short	Long	Description
-c	--comment	Comment field contents. Traditionally it contains the user’s full name. Optional.
-d	--home or --home-dir	User’s home directory specification. Default action is set by the HOME and CREATE_HOME directives.
-D	--defaults	Display /etc/default/useradd directives.
-e	--expiredate	Date of account’s expiration in YYYY-MM-DD format. Default action is set by the EXPIRE directive.
-f	--inactive	Number of days after a password has expired and has not been changed until the account will be deactivated. A -1 indicates account will never be deactivated. Default action is set by the INACTIVE directive.
-g	--gid	Account’s group membership, which is active when user logs into system (default group).
-G	--groups	Account’s additional group memberships.
-m	--create-home	If it does not exist, create the user account’s home directory. Default action is set by the CREATE_HOME directive.
-M	N/A or --no-create-home	Do not create the user account’s home directory. Default action is set by the CREATE_HOME directive.
-s	--shell	Account’s shell. Default action is set by the SHELL directive.
-u	--uid	Account’s User Identification (UID) number.
-r	--system	Create a system account instead of a user account.

We need to employ a few of the options in Table 10.5 to create a user account on the Ubuntu Desktop distribution. An example is shown in Listing 10.10.

Listing 10.10: Creating a user account on Ubuntu Desktop

$ sudo useradd -md /home/JKirk -s /bin/bash JKirk
[sudo] password for Christine:
$
$ grep ^JKirk /etc/passwd
JKirk:x:1002:1002::/home/JKirk:/bin/bash
$
$ sudo grep ^JKirk /etc/shadow
JKirk:!:17806:0:99999:7:::
$
$ sudo ls -a /home/JKirk/
.  ..  .bash_logout  .bashrc  examples.desktop  .profile
$
$ sudo ls -a /etc/skel
.  ..  .bash_logout  .bashrc  examples.desktop  .profile
$

Notice in Listing 10.10 that three options are used along with the useradd command. Because this system does not have the CREATE_HOME directive set, the -m option is needed to force useradd to make a home directory for the account. The -d switch designates that the directory name should be /home/JKirk. Because the SHELL directive is set to /bin/sh on this system, the -s option is needed to set the account’s default shell to /bin/bash.

After the utility is used to create the account in Listing 10.10, notice that records now exist for the new user account in the /etc/passwd and /etc/shadow files. Also, a new directory was created, /home/JKirk, which contains files from this distro’s /etc/skel/ directory. Keep in mind at this point that no password has been added to the JKirk account yet, and thus its record in the /etc/shadow file shows ! in the password field.

 The Ubuntu and Debian distributions promote the use of the adduser program instead of the useradd utility. Their man pages refer to the useradd command as a “low-level utility.” Some other distros include a symbolic link to useradd named adduser, which may help (or not.) The adduser configuration information is typically stored in the /etc/adduser.conf file.

Another way to view account records in the /etc/passwd and /etc/shadow files is via the getent utility. For this program you pass only the file name followed by the account name whose record you wish to view. The command is employed in Listing 10.11 to view the account that was created in Listing 10.10.

Listing 10.11: Using getent to view a user account on Ubuntu Desktop

$ getent passwd JKirk
JKirk:x:1002:1002::/home/JKirk:/bin/bash
$
$ getent shadow JKirk
$
$ sudo getent shadow JKirk
JKirk:!:17806:0:99999:7:::
$

Notice in Listing 10.11 that when super user privileges are not used with getent for the shadow file, nothing is returned. This is because getent honors the security settings on the /etc/shadow file.

 If you need to modify the /etc/default/useradd file’s directive settings, instead of using a text editor, you can employ the useradd -D command. Just tack on the needed arguments. For example, to modify the SHELL directive to point to the Bash shell, use super user privileges and issue the useradd -D -s /bin/bash command.

When creating an account, you can create a password via the crypt utility and then add it when the account is created via the -p option on the useradd utility. However, that is not only cumbersome but considered a bad practice. In the next section, we’ll cover creating and managing account passwords properly.

$ sudo passwd DAdams
Changing password for user DAdams.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
$

$ sudo passwd -S DAdams
DAdams PS 2018-10-01 0 99999 7 -1 (Password set, SHA512 crypt.)
$

$ sudo chage -l DAdams
Last password change                                    : Oct 02, 2018
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 expires       : 7
$

$ sudo chage DAdams
Changing the aging information for DAdams
Enter the new value, or press ENTER for the default

        Minimum Password Age [0]: 5
        Maximum Password Age [99999]: 30
        Last Password Change (YYYY-MM-DD) [2018-10-02]:
        Password Expiration Warning [7]: 15
        Password Inactive [-1]: 3
        Account Expiration Date (YYYY-MM-DD) [-1]:
$

$ sudo usermod -L  DAdams
$
$ sudo passwd -S DAdams
DAdams LK 2018-10-01 5 30 15 3 (Password locked.)
$
$ sudo getent shadow DAdams
DAdams:!$6$B/zCaNx[…]:17806:5:30:15:3::
$
$ sudo usermod -U  DAdams
$
$ sudo passwd -S DAdams
DAdams PS 2018-10-01 5 30 15 3 (Password set, SHA512 crypt.)
$

$ sudo useradd -md /home/DBowman DBowman
$
$ sudo getent passwd DBowman
DBowman:x:1003:1003::/home/DBowman:/bin/sh
$
$ sudo usermod -s /bin/bash DBowman
$
$ sudo getent passwd DBowman
DBowman:x:1003:1003::/home/DBowman:/bin/bash
$

$ sudo ls -a /home/DBowman
.  ..  .bash_logout  .bashrc  examples.desktop  .profile
$
$ sudo getent passwd DBowman
DBowman:x:1003:1003::/home/DBowman:/bin/bash
$
$ sudo userdel -r DBowman
userdel: DBowman mail spool (/var/mail/DBowman) not found
$
$ sudo ls -a /home/DBowman
ls: cannot access ’/home/DBowman’: No such file or directory
$
$ sudo getent passwd DBowman
$

Managing Groups

Groups are organizational structures that are part of Linux’s discretionary access control (DAC). DAC is the traditional Linux security control, where access to a file, or any object, is based upon the user’s identity and current group membership. When a user account is created, it is given membership to a particular group, called the account’s default group. Though a user account can have lots of group memberships, its process can only have one designated current group at a time. The default group is an account’s current group, when the user first logs into the system.

Groups are identified by their name as well as their group identification number (GID). This is similar to how users are identified by UIDs in that the GID is used by Linux to identify a particular group, while humans use group names.

If a default group is not designated when a user account is created, then a new group is created. This new group has the same name as the user account’s name, and it is assigned a new GID. To see an account’s default group, you can use the getent command to view the /etc/passwd record for that account. Recall that the fourth field in the record is the account’s GID, which is the default group. Review Table 10.3 if you need a refresher on the various /etc/passwd record fields. Listing 10.19 shows an example of viewing an account’s default group information for the DAdams account, which was created on a Fedora Workstation distribution.

Listing 10.19: Viewing an account’s group memberships

$ getent passwd DAdams
DAdams:x:1002:1002::/home/DAdams:/bin/bash
$
$ sudo groups DAdams
DAdams : DAdams
$
$ getent group DAdams
DAdams:x:1002:
$
$ grep 1002 /etc/group
DAdams:x:1002:
$

The first command in Listing 10.19 shows that the DAdams account’s default group has a GID of 1002, but it does not provide a group name. The groups command does show the group name, which is the same as the user account name, DAdams. This is typical when no default group was designated at account creation time. The third command, another getent command, shows that the group DAdams does indeed map to the 1002 GID. The fourth command confirms this information.

To add a user to a new group or change the account’s default group, the group must preexist. This task is accomplished via the groupadd utility. The group’s GID will be automatically set by the system, but you can override this default behavior with the -g command option. An example of creating a new group is shown in Listing 10.20.

Listing 10.20: Using the groupadd utility to create a new group

$ sudo groupadd -g 1042 Project42
$
$ getent group Project42
Project42:x:1042:
$
$ grep Project42 /etc/group
Project42:x:1042:
$

Notice in Listing 10.20 that super user privileges are required to create a new group. The getent utility, as well as the grep command, is used to show the new group record in the /etc/group file. The fields in the /etc/group file are delimited by a colon (:) and are as follows:

• Group name
• Group password: An x indicates that, if a group password exists, it is stored in the /etc/gshadow file.
• GID
• Group members: User accounts that belong to the group, separated by a comma.

The new group created did not have a group password created for it. However, the x in the Project42 group record within the /etc/group file does not prove this. To make sure there is no group password, the /etc/gshadow file, where group passwords are stored, is checked in Listing 10.21.

Listing 10.21: Checking for a group password

$ sudo getent gshadow Project42
Project42:!::
$

The command in Listing 10.21 shows the Project42 group’s record within the /etc/gshadow file. The second field contains an explanation point (!), which indicates that no password has been set for this group.

Once a new group is created, you can set group membership, which is simply adding user accounts to the group. Listing 10.22 shows an example of doing this with the usermod command.

Listing 10.22: Employing usermod to add an account to a group

$ sudo groups DAdams
DAdams : DAdams
$
$ sudo usermod -aG Project42 DAdams
$
$ sudo groups DAdams
DAdams : DAdams Project42
$
$ getent group Project42
Project42:x:1042:DAdams
$

Notice that the usermod command in Listing 10.22 uses two options, -aG. The -G adds the DAdams account as a member of the Project42 group, but the -a switch is important because it preservers any previous DAdams account group memberships. After the DAdams account is added as a Project42 group member, you can see in the last two command results that the /etc/group file record for Project42 was updated.

If you need to modify a particular group, the groupmod command is helpful. A group’s GID is modified with the -g option, while a group’s name is modified with the -n switch. In Listing 10.23, the Project42 group’s GID is modified.

Listing 10.23: Using groupmod to modify a group

$ getent group Project42
Project42:x:1042:DAdams
$
$ sudo groupmod -g 1138 Project42
$
$ getent group Project42
Project42:x:1138:DAdams
$

Notice in Listing 10.23, the Project42 group’s GID is modified to 1138. The getent command confirms the /etc/group file was updated. If the 1138 GID was already in use by another group, the groupmod command would have displayed an error message and not changed the group’s GID.

To remove a group, the groupdel utility is employed. An example is shown in Listing 10.24.

Listing 10.24: Using groupdel to delete a group

$ sudo groupdel Project42
$
$ getent group Project42
$
$ sudo groups DAdams
DAdams : DAdams
$
$ sudo find / -gid 1138 2>/dev/null
$

Notice within Listing 10.24 after the Project42 group is deleted that the getent command shows that the Project42 group record has been removed from the /etc/group file. What is really nice is that any member of that deleted group has also had their group information updated as shown in the third command.

Once you have removed a group, it is important to search through the virtual directory system for any files that may have access settings for that group. You can do this audit using the find command and the deleted group’s GID. An example of this task is shown as the fourth command. If you need help remembering how to use the find utility, go back to Chapter 3, where the command was originally covered.

Besides adding, modifying, and deleting user accounts and groups, there are a few other critical items involved with administering them. These topics are covered in the next few chapter sections.

Setting Up the Environment

After a user authenticates with the Linux system and prior to reaching the Bash shell’s command-line prompt, the user environment is configured. This environment consists of environment variables, command aliases, and various other settings. For example, the PATH environment variable, covered in Chapter 3, is often manipulated in configuring the user’s environment.

The user environment configuration is accomplished via environment files. These files contain Bash shell commands to perform the necessary operations and are covered in the following sections along with a few environment variable highlights.

$ pwd
/home/Christine
$ ls .bash_profile .bash_login .profile .bashrc
ls: cannot access ’.bash_login’: No such file or directory
ls: cannot access ’.profile’: No such file or directory
.bash_profile  .bashrc
$

$ grep PS1 .bash_profile
PS1="To infinity and beyond: "
$

Querying Users

Several utilities allow you to audit which users are currently accessing the system as well as users who have accessed it in the past. You can also verify the account name you are using at present and review various information concerning user accounts.

$ whoami
Christine
$

$ who
user1    tty2         2018-10-03 13:12
Christine pts/0        2018-10-03 14:10 (192.168.0.102)
$
$ who am i
Christine pts/0        2018-10-03 14:10 (192.168.0.102)
$
$ who mom likes
Christine pts/0        2018-10-03 14:10 (192.168.0.102)
$

$ w
 09:58:31 up 49 min,  5 users,  load average: 0.81, 0.37, 0.27
USER     TTY      LOGIN@   IDLE   JCPU   PCPU WHAT
user1    tty2    09:10   49:11  43.89s  0.30s /usr/libexe[…]
Christin pts/1   09:14    2.00s  0.04s  0.01s w
Rich     tty3    09:56    1:35   0.85s  0.81s top
Kevin    tty4    09:57    1:03  16.17s 16.14s ls --color=[…]
Tim      tty5    09:57   38.00s  0.08s  0.03s nano data42[…]
$

$ id DAdams
uid=1002(DAdams) gid=1002(DAdams) groups=1002(DAdams)
$
$ id -un 1004
Kevin
$

$ grep USER /etc/profile
    USER="`id -un`"
[…]
$

$ last
Tim      tty5                          Thu Oct  4 09:57   still logged in
Kevin    tty4                          Thu Oct  4 09:57   still logged in
Rich     tty3                          Thu Oct  4 09:56   still logged in
Christin pts/1        192.168.0.102    Thu Oct  4 09:14   still logged in
user1    tty2         tty2             Thu Oct  4 09:10   still logged in
reboot   system boot  4.17.12-200.fc28 Thu Oct  4 09:09   still running
Christin pts/0        192.168.0.102    Wed Oct  3 14:10 - 15:32  (01:22)
user1    tty2                          Wed Oct  3 13:12 - 15:33  (02:21)
[…]
wtmp begins Thu Jul 26 16:30:32 2018
$

Managing Disk Space Usage

One way to prevent a filesystem from filling up with files and causing program or entire system issues is to set limits on users’ disk space usage. This is accomplished via quotas. Linux can put a cap on the number of files a user may create as well as restrict the total filesystem space consumed by a single user. Not only are these limits available for user accounts, but they also may be set for groups.

There are essentially four steps for enabling quotas on a particular filesystem. You will need to employ super user privileges to accomplish these steps. They are as follows:

1. Modify the /etc/fstab file to enable filesystem quota support.
2. If the filesystem is already mounted, unmount and remount it. If the filesystem was not previously mounted, then just mount it.
3. Create the quota files.
4. Establish user or group quota limits and grace periods.

The necessary /etc/fstab file modification is fairly simple. You just edit the file and add either usrquota or grpquota or both to the filesystem’s mount options (fourth field). An example is shown in Listing 10.33.

Listing 10.33: Setting filesystem quotas in the /etc/fstab file

$ grep /dev/sdb1 /etc/fstab
/dev/sdb1 /home/user1/QuotaFSTest ext4 defaults,usrquota,grpquota 0 0
$

Once you have the /etc/fstab file modified, if the filesystem is already mounted, you will need to unmount it via the umount command. You then mount or remount the system, using the mount -a command, which will mount any unmounted filesystems listed in the /etc/fstab file. An example is shown in Listing 10.34.

Listing 10.34: Mounting or remounting a quota enabled filesystem

# umount /dev/sdb1
# mount -a
# mount | grep /dev/sdb1
/dev/sdb1 on /home/user1/QuotaFSTest type ext4 (rw,relatime,seclabel,quota, usrquota,grpquota,
data=ordered)
#

Notice in Listing 10.34 that you can check if the mount was successful by employing the mount command and the grep utility. Also note that the mounted filesystem has both usrquota (user quotas) and grpquota (group quotas) enabled.

Once the filesystem has been properly mounted with quota support enabled, you can create the quota files needed to enforce limits. This is done via the quotacheck utility. The -c switch creates the needed files via a scan of the filesystem, recording any current quota usage. The -u option creates the aquota.user file, and the -g option creates the aquota.group file. Therefore, if you are only implementing user quotas and not group, you could leave off the -g switch and vice versa. An example of using quotacheck is shown in Listing 10.35.

Listing 10.35: Using quotacheck to create user and group quota files

# quotacheck -cug /home/user1/QuotaFSTest
#
# ls /home/user1/QuotaFSTest
aquota.group  aquota.user  lost+found
#

With the quota files created, you can start creating quota limits for user accounts and/or groups by employing the edquota utility. To edit user quotas, use the -u option (which is the default), and to edit group quotas, use the -g switch. A snipped example of editing a user account’s quota is shown in Listing 10.36.

Listing 10.36: Employing edquota to create user and group quota files

# edquota -u user1
Disk quotas for user user1 (uid 1000):
Filesystem    blocks    soft    hard  inodes   soft   hard
/dev/sdb1        212    4096    6144       2      0      0
~
[…]

When you enter the edquota command, you are put into the vim (vi) editor for the quota file, unless you have set the $EDITOR environment variable to point to another text editor. In the quota file, there are two preset items that you cannot permanently modify, blocks (blocks used) and inodes (number of current files). That is because this information was obtained when the quotacheck command was previously run and it is not set via the edquota utility.

You can, however, modify the soft and hard limits for both blocks and inodes. When you set a hard block limit, you are setting the maximum number of blocks the user can fill with data. When you set inode hard limits, you are setting the total number of files that the user can create. Once the user hits either of these limits, no more disk space or file creation is available for that account on this particular filesystem. Note that if set to 0, the limit is disabled. Notice in Listing 10.36 that inode limits are disabled.

Soft limits are a little nicer. Once the user hits a set soft limit, they can go for an extended period past this limit. It is called a grace period.

Once you have user (or group) quotas modified, you need to establish the grace period for any soft limits set. To do this, you use the edquota -t command. These grace periods are used for all users and groups. An example is shown in Listing 10.37.

Listing 10.37: Employing edquota -t to set soft limit grace periods

# edquota -t
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem     Block grace period     Inode grace period
  /dev/sdb1             7days                  7days
~

When you issue the edquota -t command, you are again thrown into the vim editor, unless you have modified the $EDITOR environment variable. Grace periods can be set for both blocks and inodes and can be a matter of days, hours, minutes, or even seconds, which doesn’t seem very graceful.

When you have modified a user’s quota limits and set grace periods, it’s a good idea to double-check your modifications. The quota command can help here. An example is shown in Listing 10.38.

Listing 10.38: Using quota to check a user’s quota limits

# quota -u user1
Disk quotas for user user1 (uid 1000):
Filesystem  blocks  quota  limit  grace  files  quota  limit  grace
/dev/sdb1     212   4096   6144             2      0      0
#

Notice in Listing 10.38 that no information is listed for the user account in the grace column. This means that the user has not gone over a soft limit and is not currently in a grace period.

After all that work, you should do another check. You can audit all your filesystems employing quota limits via the repquota command. An example is shown in Listing 10.39.

Listing 10.39: Using repquota to check all the filesystems’ quotas

# repquota -a
*** Report for user quotas on device /dev/sdb1
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --      12       0       0              1     0     0
user1     --     212    4096    6144              2     0     0
#

This should keep your filesystems humming along. However, be aware that it is a good idea to set up a periodic check of your filesystems’ quotas via the quotacheck utility. You can automate this by setting up a cron job to do so, as covered in Chapter 26.

Summary

Managing the user account and group memberships for a Linux system involves many critical pieces. You need to understand the account creation process as well as the files used. You must grasp the entire mechanism for times when troubleshooting authentication issues for a particular user is necessary. In addition, being able to use various utilities for identifying various users can assist.

User accounts may be gathered together into various groups, which provide additional access. These group memberships are part of the authorization in which users can gain entry into various files and directories. Knowing the key areas of group administration is critical for proper Linux system management.

Besides protecting your system through properly authenticated and authorization user and group mechanisms, you can also shield your filesystems from overuse. In particular, setting up filesystem user and group quotas will provide an additional layer of protection.

Exam Essentials

Describe the players in managing user accounts. The /etc/login.defs and /etc/default/useradd files configure various settings for the useradd command’s default behavior. Because the directive settings within these files vary from distribution to distribution, it is wise to peruse them prior to employing the useradd utility to create accounts. When an account is created, the /etc/passwd, /etc/shadow, and /etc/group files are all modified. Depending on the user account creation configuration, a user home directory may be created and files copied to it from the /etc/skel/ directory.

Summarize managing groups. The commands involved in creating, modifying, and deleting groups are the groupadd, groupmod, and groupdel commands. These commands cause modifications to the /etc/group file. If you need to add a user to a group, you need to employ the usermod utility. A user can easily switch from the account’s default group to another group in which the account is a member by using the newgrp program. Account group membership can be audited via the groups and getent commands as well as by viewing the /etc/group file.

Outline the environment files. The Bash shell uses environment variables to store information about the shell session and the working environment. These variables are set via environment files. Which environment files are run depend upon how a user is logging into a system as well as the distribution the account is on. User environment files are hidden files in that they begin with a dot (.) and are potentially the .bash_profile, .bash_login, .profile, and .bashrc files. Global files may include /etc/bashrc, /etc/bash.bashrc, /etc/profile, and files within the /etc/profile.d/ directory.

Explain the various methods to query user account information. There are several utilities you can employ to determine user account information for users who are currently logged into their accounts as well as those who are not. The “who” commands have three variations, which are the whoami, who, and w utilities. The id program is useful for matching UID and GID numbers to particular user accounts. The last command is helpful for viewing not only when a system has rebooted but also whether or not a user is currently logged into the system or when the last time the account was accessed.

Describe how to manage filesystem usage quotas. Prior to setting user account or group quota limits on a system, you must enable quotas on the filesystem via the usrquota and grpquota options within the /etc/fstab file. Once the filesystem is unmounted and then remounted, you can create the needed user and/or group files via the quotacheck utility. After that is accomplished, user or group limits are set via the edquota command. You can also view and/or verify quotas via the repquota program.