Managing Users and Groups
Linux was designed from the ground up to be a multiuser operating system, but a multiuser operating system would not be much good without users! And this brings us nicely to the subject of this chapter—managing users and groups in GNU/Linux.
On shared computer systems, a system administrator is usually responsible for creating, managing, and deleting user accounts. The ability of a user to access resources on a system is determined by the permissions associated with the user. Associated with each user is some “baggage,” which can include files, processes, resources, and other information. When dealing with a multiuser system, a system administrator needs to understand what constitutes a user (and the user’s baggage) and a group, how they interact together, and how they impact available system resources.
In this chapter, we will examine the technique of managing users on a single host. We’ll begin by exploring the traditional local datastore of user and group information. From there, we’ll examine the system tools available to manage the datastore automatically.
What Exactly Constitutes a User?
Under Linux, every file and program must be owned by an entity (or user). This entity can be a (human) person, a daemon, a thing, a group, and so on. Each user has a unique identifier called a user ID (UID). Each user must also belong to at least one group—a collection of users. Users may belong to multiple groups. Groups also have unique identifiers, called group IDs (GIDs).
A running program inherits the rights and permissions of the user who invokes it. (An exception to this rule is SetUID and SetGID programs, discussed in more detail later on.)
Each user’s rights can be defined in one of two ways: as those of a normal user or as a superuser. Normal users can access only what they own or have been given permission to access; permission is granted because the user either belongs to the file’s group or because the file is accessible to all users. A superuser is allowed to access all files and programs in the system. The root user is a classic example of a superuser, and these two terms are sometimes used interchangeably.
If you are accustomed to Windows, you can draw some parallels between Windows user management concepts and Linux’s user management concepts. Linux UIDs are comparable to Windows SIDs (security identifiers), for example. In contrast to Microsoft Windows, you might find the default GNU/Linux security model maddeningly simplistic: either you’re root or you’re not. Although it’s a little less common, you can also implement finer grained access control through the use of access control lists (ACLs) in Linux, as you can with Windows.
Where User Information Is Kept
If you’re already accustomed to user management in Microsoft Windows Server environments, you’re definitely familiar with Active Directory (AD), which takes care of the nitty-gritty details (LDAP, SIDs, objects, Kerberos, and so on) of the user and group database. In contrast, Linux takes the path of traditional UNIX and keeps all user information in straight text files. This is beneficial for the simple reason that it allows you to make changes to user information without the need of any complicated or specialized tools, except for a simple text editor!
Folks new to Linux administration, however, need not fear the text editor! Later on, we discuss lots of simple and intuitive user management tools that come with most GNU/Linux distributions. For now, let’s examine the text files that store user and group information in Linux.
NOTE This chapter covers the traditional Linux/UNIX methods for storing and managing user information. Chapter 27 of this book discusses some other mechanisms (such as LDAP) for storing and managing users and groups in Linux-based operating systems.
The /etc/passwd File
The /etc/passwd file stores the user’s login, encrypted password entry, UID, default GID, name (sometimes called GECOS), home directory, and login shell. Each line in the file represents information about a user. The lines are made up of various standard fields, with each field delimited by a colon. A sample entry from a passwd file with its various fields is illustrated in Figure 6-1. The fields of the /etc/passwd file are discussed in detail in the sections that follow.
Figure 6-1 Fields of the /etc/passwd file
This field is also referred to as the login field or the account field. It stores the name of the user on the system. The username must be a unique string and uniquely identifies a user to the system. Different sites use different conventions for generating human user login names.
A common method is to use the first letter of the user’s first name and append the user’s last name. This usually works, because the chances are relatively slim that an organization would have several users with the same first and last names. For example, for a user whose first name is “Ying” and whose last name is “Yang,” a username of “yyang” can be assigned. Of course, several variations of this method are also used.
This field contains the user’s encrypted password. On most modern Linux systems, this field contains a letter x to indicate that shadow passwords are being used on the system (discussed further on, in this chapter). Because security is important, every regular user or human account on the system should have a good and secure password.
TIP Choosing good passwords is always a chore. Your users will inevitably ask, “What then, O’ Mighty System Administrator, makes a good password?” Here’s a good answer: a nonlanguage word (not English, not Spanish, not Yoruba; in fact, not a human-language word), preferably with mixed case, numbers, punctuation, and high entropy—in other words, a string that looks like line noise.
Well, this is all nice and wonderful, but if a password is too hard to remember, most people will quickly defeat its purpose by writing it down and keeping it in an easily accessible location. So better make it memorable! A good technique might be to choose a phrase and then pick the first letter of every word in the phrase. Thus, the phrase “coffee is VERY GOOD for you and me” becomes ciVG4y&m. The phrase is memorable, even if the resulting password isn’t! The shadow password configuration file, /etc/login.defs, can used to configure and enforce various password parameters.
User ID Field (UID)
This field stores a unique number that the operating system and other applications use to identify the user and determine access privileges. It is the numerical equivalent of the Username field. The UID should be unique for every user.
The UID zero (0) is extra special and usually reserved for the root user. Any user who has a UID of 0 has root (administrative) access and thus has the full run (control) of the system. It is considered bad practice to allow any other users or usernames to have a UID of 0.
Different Linux distributions sometimes adopt specific UID numbering schemes. For example, newer Fedora and Red Hat Enterprise Linux (RHEL), openSUSE and Ubuntu distros reserve the UID 65534 for the user “nobody”.
Group ID Field (GID)
The next field in the /etc/passwd file is the group ID entry. It is the numerical equivalent of the primary group to which the user belongs. This field also plays an important role in determining user access privileges. It should be noted that in addition to a primary group, a user can belong to other groups as well (more on this later in the section “The /etc/group File”).
This field can store various pieces of information for a user. It can act as a placeholder for the user description, full name (first and last name), telephone number, and so on. This field is optional and as a result can be left blank. It is also possible to store multiple entries in this field by simply separating the different entries with a comma.
NOTE Of historical note, GECOS is an acronym for General Electric Comprehensive Operating System (now referred to as GECOS) and is a carryover from the early days of computing.
This is usually the user’s home directory, but it can also be any arbitrary location on the system. Each user who actually logs into the system needs a place for configuration files that are unique to that user. Along with configuration files, the directory (often referred to as the home directory) also stores the user’s personal data such as documents, code, music, photos, and so on.
The home directory allows each user to work in an environment that he or she has specifically customized—without having to worry about the personal preferences and customizations of other users.
For the sake of consistency, most sites place home directories at /home and name each user’s directory by that user’s login name. Thus, for example, if your login name were “yyang,” your home directory would be /home/yyang. The exception to this is for some special system accounts, such as a root user’s account or a system service. The superuser’s (root’s) home directory in Linux is usually set to /root. An example of a special system service account that might need a specific working directory could be a web server whose web pages are served from the /var/www/ directory.
In Linux, the decision to place home directories under /home is strictly arbitrary, but it does make organizational sense. The system really doesn’t care where we place home directories, so long as the location for each user is specified in the password file.
When users log into the system, they expect an environment that can help them be productive. When logged in at the command line, the first program that users encounter is called a shell. If you’re used to the Windows side of the world, you might equate this with command.com (cmd), Program Manager, PowerShell, or Windows Explorer.
Under GNU/Linux, most shells are text-based. A popular default user shell in Linux is the Bourne Again Shell, or Bash for short. Linux comes with several shells from which to choose—you can see most of them listed in the /etc/shells file. Deciding which shell is right for you is kind of like choosing a favorite tea or beer—what’s right for you isn’t right for everyone, but still, everyone tends to get defensive about their choice!
Interestingly enough, you are not limited only to the list of shells declared in /etc/shells. In the strictest of definitions, the password entry for each user doesn’t list what shell to run so much as it lists what program to run first for the user. Of course, most users prefer that the first program run be a shell, such as Bash.
The /etc/shadow File
This is the encrypted password file that stores the encrypted password information for user accounts. In addition to storing the encrypted password, the /etc/shadow file stores optional password aging or expiration information. The introduction of the shadow file came about because of the need to separate encrypted passwords from the /etc/passwd file. This was necessary because the ease with which the encrypted passwords could be cracked was growing with the increase in the processing power of commodity computers (home PCs). The idea was to keep the /etc/passwd file readable by all users without storing the encrypted passwords in it and then make the /etc/shadow file readable only by root or other privileged programs that require access to that information. An example of such a program would be the login program.
You might wonder, “Why not just make the regular /etc/passwd file readable by root only or other privileged programs?” Well, it isn’t that simple. By having the password file open for so many years, the rest of the system software that grew up around it relied on the fact that the password file was always readable by all users. Changing this could cause some software to fail.
Just as in the /etc/passwd file, each line in the /etc/shadow file represents information about a user. The lines are made up of various standard fields, shown next, with each field delimited by a colon:
• Login name
• Encrypted password
• Days since January 1, 1970, that password was last changed
• Days before password may be changed
• Days after which password must be changed
• Days before password is to expire that user is warned
• Days after password expires that account is disabled
• Days since January 1, 1970, that account is disabled
• A reserved field
A sample entry from the /etc/shadow file is shown here for the user account mmel:
The /etc/group File
The /etc/group file contains a list of groups, with one group per line. Each group entry in the file has four standard fields, each colon-delimited, as in /etc/passwd and/etc/shadow.
Each user on the system belongs to at least one group, that being the user’s default group. Users can then be assigned to additional groups if needed. You will recall that the /etc/passwd file contains each user’s default group ID (GID). This GID is mapped to the group’s name and other members of the group in the /etc/group file. The GID should be unique for each group.
The group file must be world-readable so that applications can test for associations between users and groups. Following are the fields of each line in /etc/group:
• Group name The name of the group
• Group password Optional, but if set, allows users who are not part of the group to join
• Group ID (GID) The numerical equivalent of the group name
• Group members A comma-separated list
A sample group entry in the /etc/group file is shown here:
This entry is for the bin group. The GID for the group is 1.
User Management Tools
One of the many benefits of having plain-text password database files that have a well-defined format is that it is easy for anyone to write custom management tools. Indeed, many site administrators have already done this to integrate their tools along with the rest of their organization’s infrastructure. For example, a new user onboarding process can be easily extended to capture, include, or update extra information such as corporate phone number, e-mail, office location, LDAP address book, and so on. Of course, not everyone wants or is able to write custom tools, which is why Linux comes with several existing tools that do the job for you.
In this section, we discuss user management tools that can be launched from the command-line interface, as well as graphical user interface (GUI) tools. Of course, learning how to use both is the preferred route, since they both have advantages.
Command-Line User Management
You can choose from among several command-line tools to perform the same actions performed by the GUI tools. Some popular command-line tools are
groupmod. The compelling advantage of using command-line tools for user management, besides speed, is the fact that the tools can usually be incorporated into other automated functions (such as scripts).
As the name implies,
useradd allows you to add a single user to the system. Unlike the GUI tools, this tool has no interactive prompts. Instead, all parameters must be specified on the command line.
Here’s the syntax for using this tool along with some oft used options:
Take note that most of the options are optional. The
useradd tool assumes preconfigured defaults in its usage. The only non-optional parameter is the
LOGIN parameter or the desired username. Also, don’t be intimidated by this long list of options! They are all quite easy to use, and some of them are described in Table 6-1.
Table 6-1 Options for the useradd Command
usermod command allows you to modify an existing user in the system. It works in much the same way as
useradd. Its usage is summarized here:
Every option you specify when using this command results in that particular parameter being modified for the user. All but one of the parameters listed here are identical to the parameters documented for the
useradd command. The one exception is
-l option allows you to change the user’s login name. This and the
-u option are the only options that require special care. Before changing the user’s login or UID, you must make sure the user is not logged into the system or running any processes. Changing this information if the user is logged in or running processes will cause unpredictable results.
userdel command does the exact opposite of
useradd—it removes existing users. This straightforward command has two commonly used optional parameters and one required parameter listed here:
The group-related commands are similar to the user commands; however, instead of working on individual users, they work on groups listed in the /etc/group file. Note that changing group information does not cause user information to be automatically changed. For example, if you remove a group whose GID is 100 and a user’s default group is specified as 100, the user’s default group would not be updated to reflect the fact that the group no longer exists.
groupadd command adds groups to the /etc/group file. The command-line options for this program are as follows:
Table 6-2 describes some common
groupadd command options.
Table 6-2 Options for the groupadd Command
Even more straightforward than
groupdel command removes existing groups specified in the /etc/group file. The only usage information needed for this command is
group is the name of the group to remove.
groupmod command allows you to modify the parameters of an existing group. The syntax and options for this command are shown here:
-g option allows you to change the GID of the group, and the
-n option allows you to specify a new name of a group. An existing GROUP name is the last parameter.
TIP Debian-based Linux distributions like Ubuntu standardize on a slight variation of the low-level command-line user and group management utilities (
groupdel, and so on) used on Red Hat–based distros. User and group management tasks on Debian-based systems are often done via the conversely named tools, such as
delgroup, and so on. The utilities
addgroup present a friendlier and interactive front-end for adding users and groups to the system. These tools consult the /etc/adduser.conf configuration file.
GUI User Managers
The obvious advantage to using the GUI tool is ease of use. It is usually just a point-and-click affair. Many of the Linux distributions come with their own GUI user managers. Fedora, CentOS, and RHEL have a utility called
system-config-users, and openSUSE/SUSE Linux Enterprise (SLE) have a YaST module that can be invoked with
yast2 users. Ubuntu uses a tool called Users Account, which is bundled with the
gnome-control-center system applet. All these tools allow you to add, edit, and maintain the users on your system. These GUIs work just fine—but you should be prepared to fall back to the command-line tools in situations where you don’t have access to the pretty GUI front-ends. Most of these interfaces can be found in the System → Administration menu within the GNOME or KDE desktop environment. They can also be launched directly from the command line.
After installing it, you can launch Fedora’s GUI user manager by typing the following:
In openSUSE or SLE, to launch the user management YaST module you’d type this:
In Ubuntu, to launch the user management tool (see Figure 6-2), you’d type this:
Figure 6-2 Ubuntu/GNOME Users Settings tool
Users and Access Permissions
Linux determines whether a user or group has access to files, programs, or other resources on a system by checking the overall effective permissions on the resource. The traditional permissions model in Linux is simple—it is based on four basic access types or rules and two special access permissions. The following access types and permissions are possible:
• (r) Read permission
• (w) Write permission
• (x) Execute permission
• (-) No permission or no access
• (s) SetUID or SetGID permission (special permission)
• (t) Sticky bit (special permission; useful for preventing users from deleting other users’ files or directories)
In addition, these permissions can be applied to three classes of users:
• Owner The owner of the file or application
• Group The group that owns the file or application
• Everyone All users
The elements of this model can be combined in various ways to permit or deny a user (or group) access to any resource on the system. There is, however, a need for an additional type of permission-granting mechanism in Linux. This need arises because every application in Linux must run in the context of a user. This is explained in the next section on SetUID and SetGID programs.
Understanding SetUID and SetGID Programs
Normally, when a program is run by a user, it inherits all of the user’s rights (or lack thereof). For example, if a user can’t read the /var/log/messages file, neither can the program/application that is needed to view the file. Note that this permission can be different from the permissions of the user who owns the program or binary. Consider the
ls program (which is used to generate directory listings), for example. It is owned by the root user. Its permissions are set so that all users of the system can run the program. Thus, if the user yyang runs
ls, that instance of
ls is bound by the permissions granted to the user yyang, not root.
However, there is an exception. Programs can be tagged with what’s called a SetUID bit (also called a sticky bit), which allows a program to be run with permissions from the program’s owner, not the user who is running it. Using
ls as an example, setting the SetUID bit on it and having the file owned by root means that if the user yyang runs
ls, that instance of
ls will run with root permissions, not with yyang’s permissions. The SetGID bit works the same way, except instead of applying to the file’s owner, it is applied to the file’s group setting.
To enable the SetUID bit or the SetGID bit, you use the
chmod command. To make a program SetUID, prefix whatever permission value you are about to assign it with a
4. To make a program SetGID, prefix whatever permission you are about to assign it with a
For example, to make
/bin/ls a SetUID program (which is a very bad idea, by the way), you would use this command:
The following variation of the
chmod command also adds the user sticky bit:
To undo the effect of the previous command, type this:
The following variation of the
chmod command removes the user sticky bit:
/bin/ls a SetGID program (which is also bad idea), you would type:
To remove the SetGID attribute from the
/bin/ls program, type:
The sticky bit is a special permission that can be used to prevent users from deleting other users’ files or directories. The sticky bit can be set by the owner of a file or directory, and the results cannot be overridden by any other users except, of course, for the superuser (root). The sticky bit is especially useful for managing the deletion of files in shared or public folders.
Let’s create a sample directory and file under the /tmp directory:
To view what the new directory looks like without the sticky bit set, type the following:
Now set the sticky bit on the directory created:
View the new directory permissions by typing this:
With the sticky bit set, another user will not be able to maliciously delete files created by the master user under the /tmp/chapter-6 folder.
You can remove the sticky bit on the folder as follows:
Pluggable Authentication Modules
Pluggable Authentication Modules (PAM) is a system of libraries that allows the use of a centralized authentication mechanism on Linux/UNIX systems. Besides providing a common authentication scheme on a system, the use of PAM allows for a lot of flexibility and control over authentication for application developers, as well as for system administrators.
Traditionally, programs that grant users access to system resources have performed the user authentication through some built-in mechanism. Although this worked great for a long time, the approach was not very scalable, and more sophisticated methods were required. This led to a number of ugly hacks to abstract the authentication mechanism, eventually leading to a Linux implementation of PAM.
The idea behind PAM is that instead of applications reading the password file, they would simply ask PAM to perform the authentication. PAM could then use whatever authentication mechanism the system administrator wanted. For many environments, the mechanism of choice is still a simple password file. And why not? It does what we want. Most users understand the need for it, and it’s a well-tested method to get the job done.
In this section, we discuss the use of PAM under the Fedora distribution. Note that although the placement of files may not be exactly the same in other distributions, the underlying configuration files and concepts still apply.
How PAM Works
PAM is to other Linux programs what a Dynamic Link Library (DLL) is to a Windows application—it is just a library. When programs need to perform authentication on some user, they call a function that exists in the PAM library. PAM provides a library of functions that an application can use to request that a user be authenticated.
When invoked, PAM checks the configuration file for that application. If it finds no application-specific configuration file, it falls back to a default configuration file. This configuration file tells the library what types of checks need to be done to authenticate the user. Based on this, the appropriate module is called upon. Fedora, RHEL, and CentOS distros store these modules in the /lib64/security or /lib/security directory.
This module can check any number of things. It can simply check the /etc/passwd file or the /etc/shadow file, or it can perform a more complex check, such as calling on an LDAP server. Once the module has made the determination, an “authenticated” or “not authenticated” message is passed back to the calling application.
If this seems like a lot of steps for what should be a simple check, you’re almost correct. Each module here is small and does its work quickly. From a user’s point of view, there should be no noticeable difference in performance between an application that uses PAM and one that does not. From a system administrator’s and developer’s point of view, the flexibility this scheme offers is incredible.
PAM’s Files and Their Locations
On a Fedora or Red Hat–type system, PAM puts configuration files in certain places. These file locations and their definitions are listed in Table 6-3.
Table 6-3 Important PAM Directories
Looking at the list of file locations in Table 6-3, you might ask why PAM needs so many different configuration files. “One configuration file per application? That seems crazy!” Well, maybe not. The reason PAM allows this is that not all applications are created equal. For instance, a Post Office Protocol (POP) mail server that uses the Dovecot mail server might want to allow all of a site’s users to fetch mail, but the login program might want to allow only certain users to log into the console. To accommodate this, PAM needs a configuration file for POP mail that is different from the configuration file for the login program.
The configuration files that we will be discussing here are located in the /etc/pam.d directory. If you want to change the configuration files that apply to specific modules in the /etc/security directory, you should consult the documentation that came with the module. Remember that PAM is just a framework, and specific modules can be written by anyone!
PAM configuration files are intrinsically interesting because of their “stackable” nature. Every line of a configuration file is evaluated during the authentication process (with the exceptions shown next). Each line specifies a module that performs some authentication task and returns either a success flag or failure flag. A summary of the results is returned to the application program calling PAM.
NOTE By “failure,” we do not mean the program did not work. Rather, we mean that when some process was undertaken to verify whether a user could do something, the return value was “NO.” PAM uses the terms “success” and “failure” to represent this information that is passed back to the calling application.
Each PAM configuration file in the /etc/pam.d/ directory consists of lines that have the syntax/format
module_type represents one of four types of modules: auth, account, session, or password. Comments must begin with the hash (#) character. Table 6-4 lists these module types and their functions.
Table 6-4 PAM Module Types
control_flag allows you to specify how you want to deal with the success or failure of a particular authentication module. Some common control flags are described in Table 6-5.
Table 6-5 PAM Control Flags
module_path specifies the relative module filename or the full path to the module that performs the authentication task. The modules are usually stored under the /lib64/security/(or /lib/security/) directory.
The final entry in a PAM configuration line is
arguments, which represents the parameters passed to the authentication module. Although the parameters are specific to each module, some generic options can be applied to all modules. Some of the more common arguments are described in Table 6-6.
Table 6-6 PAM Configuration Arguments
A Sample PAM Configuration File
Let’s examine a sample PAM configuration file, /etc/pam.d/login:
Please note that line numbers have been added to aid readability of the file.
The first line begins with a hash (#) symbol and is therefore a comment. Thus, we can ignore it:
Let’s go on to line 2:
auth, and this means that it deals with validating the user’s authentication credentials (for example, username and password). The
control_flag is set to
substack, so this line will cause a jump to the specified PAM configuration file, /etc/pam.d/system-auth. Evaluation will continue in the manner specified in the system-auth file, and control will eventually be returned to the login PAM module. There are no arguments on this line.
The rest of the lines in the file are presented before their explanation, starting with line 3:
Similar to the second line, line 3 wants to validate the user via authentication.
control_flag is set to
include. This will include all lines with the type auth from the /etc/pam.d/postlogin configuration file. There are no arguments on this line.
In line 4, the
account, and this means that it is used to restrict/permit access of an account to a system service/resource based on various factors.
required. This means that if this module fails, PAM returns a failure result to the calling application, but evaluation of the next module in the stack will continue.
pam_nologin.so (/lib64/security/pam_nologin.so) is the name of the actual PAM module to call. The pam_nologin.so module checks for the /etc/nologin file. If it is present, only root is allowed to log in; others are turned away with an error message. If the file does not exist, it always returns a success.
In line 5, the
control_flag is set to
include. This will include all lines with the type
account from the /etc/pam.d/system-auth configuration file. There are no arguments on this line.
In line 6, the
control_flag is set to
include. This will include all lines with the type password from the /etc/pam.d/system-auth configuration file. There are no arguments on this line.
Line 7 is commented out. We can thus ignore it.
In line 8, the
session, which is used for specifying what, if any, actions need to be performed before or after a user is logged in. The
control_flag is set to
pam_selinux.so (/lib64/security/pam_selinux.so) is the name of the actual PAM module to call. The pam_selinux.so module is used for setting the default security context. It is mostly popular on Red Hat–based distributions. The
close argument in this case is passed to the pam_selinux.so module.
In line 9, the
control_flag is set to
pam_loginuid.so is the name of the actual PAM module to call.
The same concepts apply to the other configuration files under the /etc/pam.d directory. If you need more information about what a particular PAM module does or about the arguments it accepts, you can consult the man page for the module. For example, to find out more about the pam_loginuid.so module, you would issue this command:
The “Other” File
As mentioned earlier, if PAM cannot find a configuration file that is specific to an application, it will use a generic configuration file instead. This generic configuration file is called /etc/pam.d/other. By default, the “other” configuration file is set to a paranoid setting so that all authentication attempts are logged and then promptly denied. It is recommended you keep it that way.
D’oh! I Can’t Log In!
Don’t worry—screwing up a setting in a PAM configuration file happens to everyone. Consider it part of learning the ropes. First thing to do: Don’t panic. Like most configuration errors under Linux, you can fix things by booting into single-user mode (Chapter 8) and fixing the errant file.
If you’ve inadvertently broken your login configuration file and need to bring it back to a sane state, here is a safe setting you can put in:
This setting will give Linux the default behavior of simply looking into the /etc/passwd or /etc/shadow file for a password. This should be good enough to get you back in, where you can make the changes you meant to make!
NOTE The pam_unix.so module is a standard Linux/UNIX authentication module. According to the module’s man page, it uses standard calls from the system’s libraries to retrieve and set account information as well as authentication. Usually, this is obtained from the /etc/passwd file and from the /etc/shadow file as well if shadow is enabled.
Like many other GNU/Linux services, PAM makes excellent use of the system log files (see Chapter 9). If things are not working the way you expect them to, begin by looking at the tail end of the log files and see if PAM is spelling out what happened. More than likely, it is. You should then be able to use this information to change your settings and fix the problem. On Red Hat–like distros, the main system log file to monitor is the /var/log/messages file, and on Debian-like distros, the equivalent log file is the /var/log/syslog file.
A Grand Tour
In this section, you’ll see real-world usage of the utilities discussed so far. We take a step-by-step approach to creating, modifying, and removing users and groups. Some new and relevant commands are also introduced and used.
Creating Users with useradd
On our sample Fedora server, we will add new user accounts and assign passwords with the
passwd commands, as follows:
1. Create a new user whose full name is “Ying Yang” with the login name (account name) of yyang. Type the following:
The user will be created with the usual Fedora default attributes. The entry in the /etc/passwd file will be
From this entry, you can tell these things about the Fedora (and RHEL) default new user values:
• The UID number is the same as the GID number. The value is 1001 in this example.
• The default shell for new users is the Bash shell (/bin/bash).
• A home directory is automatically created for all new users (for example, /home/yyang).
2. Use the
passwd command to create a new password for the username yyang. Set the password to be 19gan19, and repeat the same password when prompted. Type the following:
NOTE Several PAM modules may be called whenever the
passwd command is called. For example, on Red Hat–like distros, one of the modules is responsible for checking that the selected password meets the password strength policies on the system—policies such as the password length, complexity, and so on. The module called in the previous example is pam_pwquality.so. To learn more about this particular module, see its manual page (
3. Create another user account called mmellow for the user, with a full name of “Mel Mellow,” but this time, change the default Fedora behavior of creating a group with the same name as the username. This is accomplished by specifying the
-N option, which will cause the user to be added to the default “users” group. Type this:
4. Use the
id command to examine the properties of the user mmellow:
5. Again, use the
passwd command to create a new password for the account mmellow. Set the password to be 2owl!78, and repeat the same password when prompted:
6. Create the final user account, called bogususer. But this time, specify the user’s shell to be the tcsh shell, and let the user’s default primary group be the system “games” group:
7. Examine the /etc/passwd file for the entry for the bogususer user:
From this entry, you can tell the following: The UID is 1003, the GID is 20, the home directory is /home/bogususer, and the user shell is /bin/tcsh.
Creating Groups with groupadd
Next, we are going to create a couple of different classes of groups: system and nonsystem (Regular). Follow these steps:
1. Create a new group called research:
2. Examine the entry for the research group in the /etc/group file:
This output shows that the group ID for the research group is 1002.
3. Create another group called sales:
4. Create the final group called bogus, and force this group to be a system group (that is, the GID will be lower than 999). Type the following:
5. Examine the entry for the bogus group in the /etc/group file:
The output shows that the group ID for the bogus group is 973.
Modifying User Attributes with usermod
Now try using
usermod to change the user and group IDs for a couple of accounts.
1. Use the
usermod command to change the user ID (UID) of the bogususer to 1600:
2. Use the
id command to view your changes:
3. Use the
usermod command to change the primary GID of the bogususer account to that of the bogus group (GID = 973) and also to set an expiry date of 12-12-2021 for the account:
4. View your changes with the
5. Use the
chage command to view the new account expiration information for the user:
TIP On Red Hat–like distros such as Fedora, CentOS, and RHEL, you can grant regular users superuser privileges (root) or sudo access by adding them to the wheel group. After proper authentication, this allows a user with sudo privileges to execute a command as the superuser or another user, as specified by the system security policy. For example, to add the master user to the wheel group and thus grant sudo rights, you would run the following:
usermod master -a -G wheel
The check box asking if you want to allow the newly created user to administer the system during the initial operating system installation (Chapter 2) was essentially adding the user to the wheel group!
Modifying Group Attributes with groupmod
Now try using the
1. Use the
groupmod command to rename the bogus group as bogusgroup:
2. Again use the
groupmod command to change the GID of the newly renamed bogusgroup to 1600:
3. View your changes to the bogusgroup in the /etc/group file:
Deleting Users and Groups with userdel and groupdel
Let’s try using the
groupdel commands to delete users and groups, respectively:
1. Use the
userdel command to delete the user bogususer that you created previously. At the shell prompt, type this:
2. Use the
groupdel command to delete the bogusgroup group:
Notice that the bogusgroup entry in the /etc/group file is removed.
NOTE When you run the
userdel command with only the user’s login specified on the command line (for example,
userdel bogususer), all of the entries in the /etc/passwd and /etc/shadow files, as well as references in the /etc/group file, are automatically removed. But if you use the optional
-r parameter, all of the files owned by the user in that user’s home directory are removed as well.
TIP The virtual machine images used in popular cloud environments, such as Amazon Web Services (AWS), Google Compute Platform (GCP), and Linode, tend to standardized on certain username and/or authentication schemes. For example, AWS often has a user account named ec2-user in its VM images, and GCP usually has user accounts named after the GCP login name (google handle) or the VM’s operating system name (suse, ubuntu, fedora, and so on). For Microsoft’s Azure, you usually have the choice of specifying the username at the time of launching the VM instance. Native FOSS VM bootstrapping tools such as virt-builder usually have mechanisms for allowing you to specify or create user accounts (and credentials) at the time of image compilation.
This chapter discussed the ins and outs of user and group management under GNU/Linux. Much of what you read here also applies to numerous GNU/Linux distributions. which makes administering users in heterogeneous environments much easier.
Among other things, the following main points were covered in this chapter:
• Each user gets a unique UID, and each group gets a unique GID.
• The /etc/passwd file maps UIDs to usernames.
• GNU/Linux handles encrypted passwords in multiple ways.
• GNU/Linux includes a multitude of tools to help you administer users.
• Linux can store user and group information in various databases that have a standard format and structure.
• Pluggable Authentication Modules (PAM) is Linux’s generic way of handling multiple authentication mechanisms.
These concepts may be pretty foreign to an administrator coming from a Microsoft Windows environment and can be a little tricky at first. Not to worry, though—the GNU/Linux security model is quite straightforward, and as such you will quickly get comfortable with how it all works.