16.

1 Introduction
During the installation process, most installers create a normal user and either give this user the
permission to execute administrative commands with sudo or require the root user account
password be configured as part of the installation process. Most Linux systems are configured to
allow for one unprivileged (non-root) user to log in, as well as have the ability to effectively execute
commands as the root user, either directly or indirectly.

If the computer is to be used by only one person, then having only one regular user account might
be sufficient. However, if a computer needs to be shared by multiple people, then it is desirable to
have a separate account for each person who uses it. There are several advantages to individuals
having their own separate accounts:

Accounts can be used to grant selective access to files or services. For example, the user of each
account has a separate home directory that is generally not accessible to the other users.

The sudo command can be configured to grant the ability to execute select administrative
commands. If users are required to use the sudo command to perform administrative commands,
then the system logs when users perform these commands.

Each account can have group memberships and rights associated with it allowing for greater
management flexibility.

On some distributions, creating a new user account also automatically creates a group account for
the user, called a User Private Group (UPG) . On these systems, the group and username would be
the same, and the only member of this new group would be the new user.

For distributions that do not create a UPG, new users are typically given the users group as their
primary group. The administrator can manually create group accounts that are private for the user,
but it's more common for the administrator to create groups for multiple users that need to
collaborate. User accounts can be modified at any time to add or remove them from group account
memberships, but users must belong to at least one group for use as their primary group.

Before you begin creating users, you should plan how to use groups. Users can be created with
memberships in groups that already exist, or existing users can be modified to have memberships in
existing groups.

If you already have planned which users and groups you want, it is more efficient to create your
groups first and create your users with their group memberships. Otherwise, if you create your users
first, and then your groups, you'll need to take an extra step to modify your users to make them
members of your groups.

16.2 Groups
The most common reason to create a group is to provide a way for users to share files. For
example, if several people who work together on the same project and need to be able to
collaborate on documents stored in files for the project. In this scenario, the administrator can
make these people members of a common group, change the directory ownership to the new
group and set permissions on the directory that allows members of the group to access the files.
 After creating or modifying a group, you can verify the changes by viewing the group
configuration information in the /etc/group file with the grep command. If working with
network-based authentication services, then the getent command can show you both local and
network-based groups.
grep pattern filename
getent database record

For local usage, these commands show the same result, in this case for the root group:

root@localhost:~# grep root /etc/group

root:x:0:
root@localhost:~# getent group root
root:x:0:

​
​

[Link] Group ID Considerations

In some Linux distributions, particularly those based upon Red Hat, when a user ID (UID) is
created, a user private group (UPG) is also created with that user as its only member. In these
distributions, the UID and the ID of the UPG are supposed to match (be the same number).

Therefore, you should avoid creating GIDs in the same numeric ranges where you expect to
create UIDs, to avoid a conflict between a GID you create and a UPG number that is created to
match a UID.

GIDs under either 500 (RedHat) or 1000 (Debian) are reserved for system use. There may be
times at which you want to assign a lower GID value. To accomplish this, use the -r option which
assigns the new group a GID that is less than the lowest standard GID:
root@localhost:~# groupadd -r sales
root@localhost:~# getent group sales
sales:x:999:

​
​

[Link] Group Naming Considerations

Following these guidelines for group names can help to select a group name that is portable
(function correctly with other systems or services):
 ●​ The first character of the name should be either an underscore _ character or a
lowercase alphabetic a-z character.
●​ Up to 32 characters are allowed on most Linux distributions, but using more than 16 can
be problematic as some distributions may not accept more than 16.
●​ After the first character, the remaining characters can be alphanumeric, a dash -
character or an underscore _ character.
●​ The last character should not be a hyphen - character.

Unfortunately, these guidelines are not always enforced. The problem isn't that the groupadd
command does not necessarily fail, but that other commands or system services may not work
correctly.

​
​

16.2.2 Modifying a Group

The groupmod command can be used to either change the name of a group with the -n option or
change the GID for the group with the -g option.

Changing the name of the group may confuse users who were familiar with the old name and
haven't been informed of the new name. However, changing the group name won't cause any
problems with accessing files, since the files are owned by GIDs, not group names. For example:
root@localhost:~# ls -l [Link]
-rw-r-----. 1 root sales 0 Aug 1 13:21 [Link]
root@localhost:~# groupmod -n clerks sales
root@localhost:~# ls -l [Link]
-rw-r-----. 1 root clerks 0 Aug 1 13:21 [Link]

Note: The file in the example above is not available within the virtual machine environment of this
course.

After the previous groupmod command, the [Link] file has a different group owner name.
However, all users who were in the sales group are now in the clerks group, so all of those
users can still access the [Link] file. Again, this is because the system defines the group
by the GID, not the group name.

On the other hand, if you change the GID for a group, then all files that were associated with that
group will no longer be associated with that group. In fact, all files that were associated with that
group will no longer be associated with any group name. Instead, these files will be owned by a
GID only, as shown below:
root@localhost:~# groupmod -g 10003 clerks
root@localhost:~# ls -l [Link]
-rw-r-----. 1 root 491 13370 Aug 1 13:21 [Link]
 Consider This

These files with no group name are called orphaned files . To search for all files that are owned
by just a GID (not associated with a group name) use the -nogroup option of the find
command:

root@localhost:~# find / -nogroup

/root/[Link]

​
​

16.2.3 Deleting a Group

If you decide to delete a group with the groupdel command, be aware that any files that are
owned by that group will become orphaned.

Only supplemental groups can be deleted, so if any group that is the primary group for any user,
it cannot be deleted. The administrator can modify which group is a user's primary group, so a
group that was being used as a primary group can be made into a supplemental group and then
can be deleted.

As long as the group to be deleted is not a user's primary group, deleting the group is
accomplished by using the groupdel command along with the name of the group:

root@localhost:~# groupdel clerks

​
​

16.3 Users
User account information is stored in the /etc/passwd file and user authentication information
(password data) is stored in the /etc/shadow file. Creating a new user can be accomplished by
manually adding a new line to each of these files, but that is generally not the recommended
technique.

By using an appropriate command to add a new user, these files can be modified automatically
and safely. If you were to modify these files manually, you would risk making a mistake that could
prevent all users from being able to log in normally.

Before you begin creating users for your system, you should verify or establish practical values
that are used by default with the useradd command. These settings can be found in the
configuration files that are used by the useradd command.
 Ensuring that the values in these configuration files are reasonable before adding users can help
save you the time and trouble of having to correct user account settings after adding the users.

​
​

16.3.1 User Configuration Files

The -D option to the useradd command allows you to view or change some of the default values
used by the useradd command. The values shown by useradd -D can also be viewed or
updated by manipulating the /etc/default/useradd file:

root@localhost:~# useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

The following describes each of these values:

​ Group​
GROUP=100​
In distributions not using UPG, this is the default primary group for a new user, if one is
not specified with the useradd command. This is usually the users group with a GID of
100.​
This setting affects the primary group ID field of the /etc/passwd file highlighted
below:​
bob:x:600:600:bob:/home/bob:/bin/bash​
The -g option to the useradd command allows you to use a different primary group than
the default when creating a new user account.
​ Home​
HOME=/home​
The /home directory is the default base directory under which the user's new home
directory is created. This means that a user with an account name of bob would have a
home directory of /home/bob.​
This setting affects the home directory field of the /etc/passwd file highlighted below:​
bob:x:600:600:bob:/home/bob:/bin/bash​
The -b option to the useradd command allows you to use a different base directory
group than the default when creating a new user account.
​ Inactive​
INACTIVE=-1​
This value represents the number of days after the password expires that the account is
disabled. A value of -1 means this feature is not enabled by default and no "inactive"
 value is provided for new accounts by default.​
This setting affects the inactive field of the /etc/shadow file highlighted below:​
bob:pw:15020:5:30:7:60:15050:​
The -f option to the useradd command allows you to use a different INACTIVE value
than the default when creating a new user account.
​ Expire​
EXPIRE=​
By default, there is no value set for the expiration date. Usually, an expiration date is set
on an individual account, not all accounts by default.​
For example, if you had a contractor that was hired to work until the end of the day on
November 1, 2019, then you could ensure that they would be unable to log in after that
date by using the EXPIRE field.​
This setting affects the expire field of the /etc/shadow file highlighted below:​
bob:pw:15020:5:30:7:60:15050:​
The -e option to the useradd command allows you to use a different EXPIRE value than
the default when creating a new user account.
​ Shell​
SHELL=/bin/bash​
The SHELL setting indicates the default shell for a user when they log in to the system.​
This setting affects the shell field of the /etc/passwd file highlighted below:​
bob:x:600:600:bob:/home/bob:/bin/bash​
The -s option to the useradd command allows you to use a different login shell than the
default when creating a new user account.
​ Skeleton Directory​
SKEL=/etc/skel​
The SKEL value determines which skeleton directory has its contents copied into the
new user’s home directory. The contents of this directory are copied into the new user's
home directory, and the new user is given ownership of the new files.​
This setting provides administrators with an easy way to populate a new user account
with key configuration files.​
The -k option to the useradd command allows you to use a different SKEL directory than
the default when creating a new user account.
​ Create Mail Spool​
CREATE_MAIL_SPOOL=yes​
A mail spool is a file where incoming email is placed.​
Currently, the value for creating a mail spool is yes, which means that users by default
are configured with the ability to receive and store local mail. If you are not planning on
using local mail, then this value could be changed to no.

To modify one of the useradd default values, the /etc/default/useradd file could be edited
with a text editor. Another (safer) technique is to use the useradd -D command.

For example, if you wanted to allow users to have expired passwords that they could still log in
with for up to thirty days, then you could execute:
root@localhost:~# useradd -D -f 30
root@localhost:~# useradd -D
GROUP=100
HOME=/home
INACTIVE=30
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

​
​

16.3.2 User Configuration Files

The /etc/[Link] file also contains values that are applied by default to new users you
create with the useradd command. Unlike the /etc/default/useradd file, the
/etc/[Link] file is usually edited directly by the administrator to alter its values.

This file contains many comments and blank lines, so to only view lines that are not comments or
blank lines (the real configuration settings), then you can use the following grep command:

root@localhost:~# grep -Ev '^#|^$' /etc/[Link]

MAIL_DIR​ /var/mail/spool
PASS_MAX_DAYS​ 99999
PASS_MIN_DAYS​ 0
PASS_MIN_LEN​5
PASS_WARN_AGE​ 7
UID_MIN​ ​ ​ 500
UID_MAX​ ​ ​ 60000
GID_MIN​ ​ ​ 500
GID_MAX​ ​ ​ 60000
CREATE_HOME​ yes
UMASK 077
USERGROUPS_ENAB yes
ENCRYPT_METHOD SHA512
MD5_CRYPT_ENAB no

The above example represents a typical CentOS 6 distribution /etc/[Link] file with its
values. The following describes each of these values:

​ Mail Directory​
MAIL_DIR​ ​ /var/mail/spool​
The directory in which the user's mail spool file is created.
​ Password Maximum Days​
PASS_MAX_DAYS​ 99999​
This setting determines the maximum number of days that a user can continue to use the
same password. Since it defaults to 99999 days (over 200 years) it effectively means
 users never have to change their password.​
Organizations with effective policies for maintaining secure passwords typically change
this value to 60 or 30 days.​
This setting affects the default setting of the /etc/shadow file highlighted below:​
bob:pw:15020:5:30:7:60:15050:
​ Password Minimum Days​
PASS_MIN_DAYS​ 0​
With this set to a default value of zero, the shortest time that a user is required to keep a
password is zero days, which means that they can immediately change a password that
they have just set.​
If the PASS_MIN_DAYS value was set to three days, then after setting a new password,
the user would have to wait three days before they could change it again.​
This setting affects the default setting of the /etc/shadow file highlighted below:​
bob:pw:15020:3:30:7:60:15050:
​ Password Minimum Length​
PASS_MIN_LEN​ 5​
This indicates the minimum number of characters that a password must contain.
​ Password Warning​
PASS_WARN_AGE​ 7​
This is the default for the warning field. As a user approaches the maximum number of
days that they can use their password, the system checks to see if it is time to start
warning the user about changing their password at login.​
This setting affects the default setting of the /etc/shadow file highlighted below:​
bob:pw:15020:3:30:7:60:15050:
​ UID Minimum​
UID_MIN​ ​ ​ 500​
The UID_MIN determines the first UID that is assigned to an ordinary user. Any UID less
than this value would either be for a system account or the root account.
​ UID Maximum​
UID_MAX​ ​ ​ 60000​
A UID technically could have a value of over four billion. For maximum compatibility, it's
recommended to leave it at its default value of 60000.
​ GID Minimum​
GID_MIN​ ​ ​ 500​
The GID_MIN determines the first GID that is assigned to an ordinary group. Any group
with a GID less than this value would either be a system group or the root group.
​ GID Maximum​
GID_MAX​ ​ ​ 60000​
A GID, like a UID, could have a value of over four billion. Whatever value you use for
your UID_MAX, should be used for GID_MAX to support UPG.
​ Home Directory​
CREATE_HOME​yes​
The value of this determines whether or not a new directory is created for the user when
their account is created.​
Our virtual machines do not include this value. Therefore a home directory is not created
for new users unless specified.
 ​ Umask​
UMASK 077​
UMASK works at the time the user home directory is being created; it determines what
default permissions are placed on this directory. Using the default value of 077 for UMASK
means that only the user owner has any kind of permission to access their directory.
The UMASK value will be covered in more detail in the chapter on permissions.
​ UPG​
USERGROUPS_ENAB yes​
In distributions that feature a private group for each user, as this CentOS example shows,
the USERGROUPS_ENAB will have a value of yes. If UPG is not used in the distribution,
then this will have a value of no.
​ Encryption​
ENCRYPT_METHOD SHA512​
The encryption method that is used to encrypt the users' passwords in the /etc/shadow
file. The ENCRYPT_METHOD setting overrides the MD5_CRYPT_ENAB setting.
​ Encryption (Deprecated)​
MD5_CRYPT_ENAB no​
This deprecated setting originally allowed the administrator to specify using MD5
encryption of passwords instead of the original DES encryption. It has been superseded
by the ENCRYPT_METHOD setting.

​
​

16.3.3 Account Considerations

Creating a user account for use with a Linux system may require that you gather several pieces
of information. While all that may be required is the account name, you may also want to plan the
UID, the primary group, the supplementary groups, the home directory, the skeleton directory,
and the shell to be used. When planning these values, consider the following:

Username

The only required argument for the useradd command is the name you want the account to
have. The username should follow the same guidelines as for group names. Following these
guidelines can help you to select a username that is portable:

●​ The first character of the name should be either an underscore _ character or a

lower-case alphabetic a-z character.
●​ Up to 32 characters are allowed on most Linux distributions, but using more than 16 can
be problematic as some distributions may not accept more than 16.
●​ After the first character, the remaining characters can be alphanumeric, a dash -
character or an underscore _ character.
●​ The last character should not be a hyphen - character.

If the user needs to access multiple systems, it is usually recommended to have the account
name be the same on those systems. The account name must be unique for each user.
root@localhost:~# useradd jane

User Identifier (UID)

Once you create a user with a specific UID, the system generally increments the UID by one for
the next user that you create. If attached to a network with other systems, you may want to
ensure that this UID is the same on all systems to help provide consistent access.

Adding the -u option to the useradd command allows you to specify the UID number. UIDs
typically can range anywhere from zero to over four billion, but for greatest compatibility with
older systems, the maximum recommended UID value is 60,000.
root@localhost:~# useradd -u 1000 jane

The root user has a UID of 0, which allows that account to have special privileges. Any account
with a UID of 0 would effectively be able to act as the administrator.

System accounts are generally used to run background services called daemons . By not
having services run as the root user, the amount of damage that can be done with a
compromised service account is limited. System accounts used by services generally use UIDs
that are in the reserved range. One system account that is an exception to this rule is the user
nfsnobody, which has a UID of 65534.

The reserved range used for service accounts has expanded over time. Initially, it was for UIDs
between 1 and 99. Then, it expanded to be between 1 and 499. The current trend among
distributions is that system accounts are any account that has a UID between 1 and 999, but the
range 1-499 is also still commonly used.

When setting up a new system, it is a good practice to start UIDs no lower than 1000 ensuring
there are sufficient UIDs available for many system services and giving you the ability to create
many GIDs in the reserved range.

Primary Group

In distributions which feature UPG, this group is created automatically with a GID and group
name that matches the UID and username of the newly created user account. In distributions not
using UPG, the primary group ordinarily defaults to the users group with a GID of 100.

To specify a primary group with the useradd command, use the -g option with either the name or
GID of the group. For example, to specify users as the primary group:

root@localhost:~# useradd -g users jane

Supplementary Group

To make the user a member of one or more supplementary groups, the -G option can be used to
specify a comma-separated list of group names or numbers. For example to specify sales and
research as supplementary groups:
root@localhost:~# useradd -G sales,research jane

Home Directory

By default, most distributions create the user's home directory with the same name as the user
account underneath whichever base directory is specified in the HOME setting of the
/etc/default/useradd file, which typically specifies the /home directory. For example, if
creating a user account named jane, the user's new home directory would be /home/jane.

root@localhost:~# useradd jane

root@localhost:~# grep '/home/jane' /etc/passwd
jane:x:1008:1010::/home/jane:/bin/sh

There are several options for the useradd command that can affect creating the user's home
directory:

●​ If CREATE_HOME is set to no or this setting is not present, then the directory will not be
created automatically. Otherwise, the -M option is used to specify to the useradd
command that it should not create the home directory, even if CREATE_HOME is set to
yes.

If the CREATE_HOME setting in the /etc/[Link] file is set to yes, the home directory is
created automatically. Otherwise, the -m option can be used to make the home directory.​
root@localhost:~# useradd -m jane
root@localhost:~# ls -ld /home/jane
drwxr-xr-x 2 jane jane 4096 Dec 18 19:14 /home/jane
●​

The -b option allows you to specify a different base directory under which the user's home
directory is created. For example, the following creates the user account jane with a /test/jane
created as the user’s home directory:​
root@localhost:~# useradd -mb /test jane
root@localhost:~# ls -ld /test/Jane
drwxr-xr-x 2 jane jane 4096 Dec 18 19:16 /test/jane
●​

The -d option allows you to specify either an existing directory or a new home directory to create for
the user. This should be a full path for the user's home directory. For example, the following
creates the user account jane with a /test/jane created as the user’s home directory:​
root@localhost:~# useradd -md /test/jane jane
root@localhost:~# ls -ld /test/jane
drwxr-xr-x 2 jane jane 4096 Dec 18 19:19 /test/jane
●​
●​ The -k option to specifies a different skeleton directory. When using the -k option, the -m
option is required.

Skeleton Directory
 By default, the contents of the /etc/skel directory are copied into the new user's home
directory. The resulting files are also owned by the new user. By using the -k option with the
useradd command, the contents of a different directory can be used to populate a new user's
home directory. When specifying the skeleton directory with the -k option, the -m option must be
used or else the useradd command will fail with an error.

The following example uses /home/sysadmin as the skeleton directory:

root@localhost:~# useradd -mk /home/sysadmin jane

root@localhost:~# ls /home/jane
Desktop Documents Downloads Music Pictures Public Templates Videos

Shell

While the default shell is specified in the /etc/default/useradd file, it can also be
overridden with the useradd command using the -s option at the time of account creation:

root@localhost:~# useradd -s /bin/bash jane

It is common to specify the /sbin/nologin shell for accounts to be used as system accounts.

Comment

The comment field, originally called the General Electric Comprehensive Operating System
(GECOS) field, is typically used to hold the user's full name. Many graphical login programs
display this field's value instead of the account name. The -c option of the useradd command
allows for the value of this field to be specified.
root@localhost:~# useradd -c 'Jane Doe' jane

​
​

16.3.4 Creating a User

Once you've verified which default values to use and you've gathered the information about the
user, then you are ready to create a user account. An example of a useradd command using a
few options looks like the following:
root@localhost:~# useradd -u 1009 -g users -G sales,research -m -c 'Jane Doe'
jane

This example of the useradd command creates a user with a UID of 1009, a primary group of
users, supplementary memberships in the sales and research groups, a comment of "Jane
Doe", and an account name of jane.
 After executing the previous command, the information about the jane user account is
automatically added to the /etc/passwd and /etc/shadow files, while the information about
supplemental group access is automatically added to the /etc/group and /etc/gshadow
files:
root@localhost:~# grep jane /etc/passwd
jane:x:1009:100:Jane Doe:/home/jane:/bin/sh
root@localhost:~# grep jane /etc/shadow
jane:!:17883:0:99999:7:30::
root@localhost:~# grep jane /etc/group
research:x:1005:jane
sales:x:999:jane
root@localhost:~# grep jane /etc/gshadow
research:!::jane
sales:!::jane

⁠​‌
Note that the account doesn't have a valid password yet!

In addition, if the CREATE_MAIL_SPOOL is set to yes then the mail spool file
/var/spool/mail/jane is created:

root@localhost:~# ls /var/spool/mail
jane root rpc sysadmin

Finally, because the -m option is used, the /home/jane directory is created with permissions
only permitting the jane user access, and the contents of the /etc/skel directory would be
copied into the directory:
root@localhost:~# ls /home
jane sysadmin

​
​

16.3.5 Passwords
Choosing a good password is not an easy task, but it is critical that it is done properly or the
security of an account (perhaps the entire system) could be compromised. Picking a good
password is only a start; you need to be very careful with your password so that it is not revealed
to other people. You should never tell anyone your password and never let anyone see you type
your password. If you do choose to write down your password, then you should store it securely
in a place like a safe or safe deposit box.
It's easy to make a bad password! If you use any information in your password that is related to
you, then this information can also be known or discovered by others, resulting in your password
being easily compromised. Your password should never contain information about you or anyone
you know, such as your first name, middle name, last name, birthday, phone, pet names, drivers
license, or social security number.

There are numerous factors to consider when you are trying to choose a password for an
account:

●​ Length: The /etc/[Link] file allows the administrator to specify the minimum
length of the password. While some believe that the longer the password, the better, this
isn't really correct. The problem with passwords that are too long is that they are not
easily remembered and, as a result, they are often written down in a place where they
can easily be found and compromised.
●​ Composition: A good password should be composed of a combination of alphabetic,
numeric and symbolic characters.
●​ Lifetime: The maximum amount of time that a password can be used should be limited
for several reasons:
○​ If an account is compromised and the time that the password is valid is limited,
the intruder will ultimately lose access when the password becomes invalid.
○​ If an account is not being used, then it can automatically be disabled when the
password is no longer valid.
○​ If attackers are attempting a "brute-force" attack by trying every possible
password, then the password can be changed before the attack can succeed.
●​ However, requiring a user to change their password too often might pose security
problems, including:
○​ The quality of the password the user chooses might suffer.
○​ The user may start writing their password on paper, increasing the possibility that
the password may be discovered.
○​ Seldom used user accounts may become expired and require administrative
attention to reset.

Opinions vary about how often users should be forced to change their passwords. For
highly-sensitive accounts, it is recommended to change passwords more frequently, such as
every 30 days. On the other hand, for non-critical accounts without any access to sensitive
information, there is less need for frequent change. For accounts with minimal risk, having a
duration of 90 days would be considered more reasonable.

​
​

[Link] Setting a User Password

There are several ways for a user password to be changed. The user can execute the passwd
command, the administrator can execute the passwd command providing the username as an
argument, or graphical tools are also available.
 The administrator can use the passwd command to either set the initial password or change the
password for the account. For example, if the administrator had created the account jane, then
executing passwd jane provides the administrator a prompt to set the password for the jane
account. If completed successfully, then the /etc/shadow file will be updated with the user's new
password.

While regular users must follow many password rules, the root user only needs to follow one
rule: the password cannot be left blank. When the root user violates all other password rules that
normally apply to regular users, it results in a warning being printed to the screen and the rule not
being enforced:
root@localhost:~# passwd Jane
Enter new UNIX password:
BAD PASSWORD: it is WAY to short
BAD PASSWORD: is too simple
Retype new UNIX password:

Assuming that the administrator has set a password for a user account, the user can then log in
with that account name and password. After the user opens a terminal, they can execute the
passwd command with no arguments to change their own password. They are prompted for their
current password and then prompted to enter the new password twice.

As an ordinary user, it may be difficult to set a valid password because all of the rules for the
password must be followed. The user is normally allowed three attempts to provide a valid
password before the passwd command exits with an error.

Using the privileges of the root user, the encrypted passwords and other password-related
information can be viewed by viewing the /etc/shadow file. Recall that regular users cannot
see the contents of this file.

​
​

[Link] Managing Password Aging

The chage command provides many options for managing the password aging information found
in the /etc/shadow file.

Here's a summary of the chage options:

Short
Option Long Option Description
 -l --list List the account aging information

-d --lastday LAST_DA Set the date of the last password chan

LAST_DAY to LAST_DAY

-E --expiredate Set account to expire on EXPIRE_DAT

EXPIRE_D EXPIRE_DATE

-h --help Show the help for the chage command

-I --inactive Set account to permit login for INACTI

INACTIVE INACTIVE
days after password expires

-m --mindays MIN_DAY Set the minimum number of days befo

MIN_DAYS the password can be changed to
MIN_DAYS

-M --maxdays MAX_DAY Set the maximum number of days befo

MAX_DAYS a password should be changed to
MAX_DAYS

-W --warndays Set the number of days before a

WARN_DAY WARN_DAYS password expires to start displaying a
warning to WARN_DAYS

A good example of the chage command would be to change the maximum number of days that
an individual's password is valid to be 60 days:
root@localhost:~# chage -M 60 jane
root@localhost:~# grep jane /etc/shadow | cut -d: -f1,5
jane:60

​
 ​

16.3.6 Modifying a User

Before making changes to a user account, understand that some commands will not successfully
modify a user account if the user is currently logged in (such as changing the user's login name).

Other changes that you might make won't be effective if the user is logged in, but will become
effective as soon as the user logs out and then logs back in again. For example, when modifying
group memberships, the new memberships will be unavailable to the user until the next time the
user logs in.

In either case, it is helpful to know how to use the who, w, and last commands, so you can be
aware of who is logged into the system, as this may impact the changes that you want to make to
a user account.

Both the who and the w commands display who is currently logged into the system. The w
command is the more verbose of the two, as it shows the system's uptime and load information
as well as what process each user is running. The last command can be used to determine
current and previous login sessions as well as their specific date and time. By providing a
username or a tty (terminal) name as an argument, the command only shows records that
match that name.

The usermod command offers many options for modifying an existing user account. Many of
these options are also available with the useradd command at the time the account is created.
The following chart provides a summary of the usermod options:

Short
Option Long Option Description

-c COMMENT Sets the value of the GECOS or

comment field to COMMENT.

-d --home HOME_DIR Sets HOME_DIR as a new home direct

HOME_DIR
for the user.

-e --expiredate Set account expiration date to

EXPIRE_D EXPIRE_DATE EXPIRE_DATE.
 -f --inactive Set account to permit login for
INACTIVE INACTIVE INACTIVE days after password expire

-g GROUP --gid GROUP Set GROUP as the primary group.

-G GROUP --groups GROUPS Set supplementary groups to a list

specified in GROUPS.

-a --append Append the user's supplemental group

with those specified by the -G option.

-h --help Show the help for the usermod

command.

-l --login NEW_LOGIN Change the user's login name.

NEW_LOGI

-L --lock Lock the user account.

-s SHELL --shell SHELL Specify the login shell for the account.

-u --uid NEW_UID Specify the user's UID to be NEW_UID

NEW_UID

-U --unlock Unlock the user account.

Several of these options are worthy of discussion because of how they impact user
management. It can be very problematic to change the user's UID with the -u option, as any files
owned by the user will be orphaned. On the other hand, specifying a new login name for the user
with -l does not cause the files to be orphaned.

Deleting a user with the userdel command can either orphan or remove the user's files on the
system. Instead of deleting the account, another choice is to lock the account with the -L option
 for the usermod command. Locking an account prevents the account from being used, but
ownership of the files remains.

There are some important things to know about managing the supplementary groups. If you use
the -G option without the -a option, then you must list all the groups to which the user would
belong. Using the -G option alone can lead to accidentally removing a user from all the former
supplemental groups that the user belonged to.

If you use the -a option with -G then you only have to list the new groups to which the user would
belong. For example, if the user jane currently belongs to the sales and research groups,
then to add her account to the development group, execute the following command:

root@localhost:~# usermod -aG development jane

​
​

16.3.7 Deleting a User

The userdel command is used to delete users. When you delete a user account, you also need
to decide whether to delete the user's home directory. The user's files may be important to the
organization, and there may even be legal requirements to keep the data for a certain amount of
time, so be careful not to make this decision lightly. Also, unless you've made backup copies of
the data, once you've executed the command to delete the user and their files, there is no
reversing the action.

To delete the user jane without deleting the user's home directory /home/jane, execute:

root@localhost:~# userdel jane

Beware that deleting a user without deleting their home directory means that the user's home
directory files will be orphaned and these files will be owned solely by their former UID and GID.

To delete the user, home directory, and mail spool as well, use the -r option:

root@localhost:~# userdel -r jane

WARNING

The above command will only delete the user's files in their home directory and their mail spool.
If the user owns other files outside of their home directory, then those files will continue to exist
as orphaned files.

​
​