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:

•
•

16.2.1 Creating A Group

The groupadd command can be executed by the root user to create a new group. The
command requires only the name of the group to be created. The -g option can be used to
specify a group id for the new group:

root@localhost:~# groupadd -g 1005 research

root@localhost:~# grep research /etc/group
research:x:1005:

If the -g option is not provided, the groupadd command will automatically provide a GID for
the new group. To accomplish this, the groupadd command looks at the /etc/group file
and uses a number that is one value higher than the current highest GID number. The
execution of the following commands illustrates this:

root@localhost:~# groupadd development

root@localhost:~# grep development /etc/group
development:x:1006:
 •
•

[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 Vid
eos

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 'Ja

ne 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 LAST_DAY --lastday LAST_DAY Set the date of the last password change
to LAST_DAY

- -- Set account to expire on EXPIRE_DATE

E EXPIRE_DATE expiredate EXPIRE_DATE

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

-I INACTIVE --inactive INACTIVE Set account to permit login

for INACTIVE days after password
expires

-m MIN_DAYS --mindays MIN_DAYS Set the minimum number of days

before the password can be changed
to MIN_DAYS

-M MAX_DAYS --maxdays MAX_DAYS Set the maximum number of days

before a password should be changed
to MAX_DAYS
 Short Option Long Option Description

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

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.
 Short Option Long Option Description

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

directory for the user.

- -- Set account expiration date

e EXPIRE_DATE expiredate EXPIRE_DATE
to EXPIRE_DATE.

-f INACTIVE --inactive INACTIVE Set account to permit login

for INACTIVE days after password
expires.

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

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

specified in GROUPS.

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

with those specified by the -G option.

-h --help Show the help for

the usermod command.

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

-L --lock Lock the user account.

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

-u NEW_UID --uid NEW_UID Specify the user's UID to be 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.

•
•