CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)
Chapter 15. Managing Users and Groups
This chapter covers the following topics:
User Account Fundamentals
Group Accounts
Adding Users and Groups
Modifying Users and Groups
Removing Users and Groups
The Shadow Suite
Changing Accounts
This chapter covers the following objectives:
Manage user and group accounts and related system files: 107.1
The importance of user and group administration cannot be emphasized enough. Your system is a target, and users are the bullets in the gun. All an attacker has to do is get a user to give the attacker his username or password and she can attempt penetration.
This chapter covers some interesting areas of system administration—supporting users and groups, enabling access, setting their default profiles and home directories, and putting the whack on them when they misbehave.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 15-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”
Table 15-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. Which UID denotes the root account?
a. 0
b. 1
c. 99
d. 100
2. Which account denotes the nobody account?
a. 0
b. 1
c. 99
d. 100
3. Based on the following entry from the /etc/group file, who is a secondary member of this group:
tim:x:599:nick
a. tim
b. x
c. 599
d. nick
4. Which useradd option specifies the user’s login shell?
a. -m
b. -d
c. -k
d. -s
5. Which option displays the defaults used by the useradd command?
a. -e
b. -D
c. -c
d. -b
6. Which command can be used to add a user to a group as a secondary group member?
a. chage
b. ulimit
c. groupmod
d. usermod
7. When removing a user with the userdel command, which option also removes the user’s home directory?
a. -r
b. -d
c. -m
d. -f
8. On modern Linux systems, which file stores the user account passwords?
a. /etc/passwd
b. /etc/password
c. /etc/shadow/password
d. /etc/shadow
9. Which commands allow you to change password aging for a user account? (Choose all that apply.)
a. usermod
b. chage
c. passwd
d. chpasswd
Foundation Topics
User Account Fundamentals
User and group accounts are not known to the kernel by the name we use and see, but by the user ID (UID) and group ID (GID) associated with the name. Early versions of the kernel supported two tables of static numbers representing up to 65,536 users and 65,536 groups, but at the 2.6 kernel version mark there were made available 4,294,967,296 possible users and groups.
The only association between the username and the UID are entries in the /etc/passwd file that defines users. The only association between the group name and the GID are entries in the /etc/group file that defines groups.
Users must have a username entry in the /etc/passwd file to log in to the system. Users cannot log in using their UID; only the username is accepted.
What Accounts Are What?
The /etc/passwd file contains a number of system accounts, all of which are assigned UIDs that range from 0 to 499. Some of the more interesting (and exam-worthy) are shown here:
0—The root user on the system.
1—The bin user, which is responsible for some system binaries and nonlogin accounts.
48—The apache user, which the HTTPD daemon runs as.
99—The nobody account, which is used for many things, particularly for anonymous access on FTP and HTTP servers. But it also maps to root accounts that attempt NFS access to shares that have been configured to deny access to the root user.
Note
I normally assign my junior sysadmin and server operator accounts UIDs in the 500–1000 range, just to differentiate them from the other users and to make keeping track of them easier. Users with UIDs between 500–1000 don’t automatically gain special privileges. However, these are the accounts that I will set up to have extra access by using the sudo command.
Normal User Accounts
Typical users are assigned UIDs ranging from 500 to 65,000. This is fine for a single system, but it can cause problems in larger environments.
If you have the need to allow for both local user accounts and network accounts (for the purpose of using NFS and NIS), it is a good idea to assign network accounts UIDs that start at the five-digit UID mark—in other words, with UIDs from 10,000 to 65,000. Local user accounts would be assigned values from 500 to 9,999. This allows for more structure in your UID numbering system.
Note
If you can, force the use of a standardized UID and GID structure across all your enterprise systems. If you have more than 100 users, consider using LDAP for managing how users log on to their systems. The now deprecated NIS and the newer LDAP methods are outside the scope of this discussion and not on the LPI Level 1 objectives but are great ways to centralize account and password management across all machines in your environment.
If you are working on a system that has both network and local accounts, displaying user account information can be tricky. Local user account data is stored in local files, such as the /etc/passwd and /etc/shadow file. Network account information is stored in databases located on a server. One command can be used to search both local and network sources for account information: the getent command. For example:
getent passwd bob
The previous command searches both local and network sources in an order determined by the /etc/nsswitch.conf file:
passwd: files nis
shadow: files nis
The value of files nis means “search local files first and then search the database for the specified value.”
User Entries in /etc/passwd
The user’s entry in the /etc/passwd file consists of the following:
ross:x:500:100:Ross Brunson:/home/ross:/bin/bash
The entries in the /etc/passwd file are
ross—The username; this must be eight or fewer characters and should be lowercase.
x—Passwords used to be stored in this file. The “x” value tells the system that the password for this account is now stored in the /etc/shadow file. For security reasons, the password should never be in the /etc/passwd file on modern Linux systems.
500—The user’s UID.
100—The user’s primary group. This group is used as the group owner of all the file objects created by this user account, except in situations where ownership inheritance has been set.
Ross Brunson—This field is a description field (also known as the GE Common Operating System, or GECOS, for historical purposes). It can be blank or have a comment or full name in it.
/home/ross—The home directory field is used to define the complete path to the user’s home directory.
/bin/bash—This field defines the login shell for the user.
Note
The GECOS field is normally just used for simple comments. However, historically it was used to specify more complex dates, including useful information like the user’s name, office location, and phone number. This information (and other user information) could be displayed with the finger command.
Special Login Files
Several files affect the user’s login experience and define when a user can log in and from where.
These files are as follows:
/bin/false—If the user’s shell is set to /bin/false, the user cannot log in. This is best used for system accounts that should never be logged in to.
/etc/nologin—When used as a login shell for a user’s account, this program displays a message that the account is unavailable and exits with a nonzero exit code. If the /etc/nologin.txt file exists, the contents of that file are shown instead of the standard message.
/etc/motd—After a successful login, the /etc/motd file contents are displayed, right before the user’s shell is executed. This is a great place for warning and legal messages to be displayed.
.hushlogin—This file, if created in the user’s home directory, changes the login process so it does not perform a mail check and does not display the last login information or the message of the day to the user.
/etc/login.defs—This file defines the defaults for when users are created by the useradd command. These defaults include entries for mail, password complexity and limitations, UID and GID minimum and maximum values, and whether the user’s home directory is created by default.
/etc/securetty—This file specifies from where the root user is allowed to log in. If it does not exist, root can log in from any location.
/etc/usertty—This file is used to set the parameters for login locations, days, times, and systems the user can connect from. The /etc/usertty file is used only on systems that don’t have PAM (pluggable authentication modules).
Watch for questions about the files listed here. Questions focus on what happens when a file exists, whether it’s assigned as a login shell, or what shows on a user’s screen when she logs in to the system.
Note
Modern Linux systems utilize a feature called PAM (pluggable authentication modules). PAM provides a rich collection of modules that allow the administrator a great deal of flexibility regarding the manner in which users are granted access to the system. While PAM is not included in the exam objectives, you should consider exploring this useful feature. Start learning about PAM by executing the command man pam.
Group Accounts
Groups come in only one type—a grouping of users. No nesting of groups is possible in Linux or Unix. Users are associated with groups using two methods:
Primary—A GID appears in the /etc/passwd file entry in the fourth field; this group is made the group owner of all created objects (files, directories, and so on) for this user. The primary group for a user is special; if a user is assigned a primary group in the /etc/passwd, she does not have to be listed as a member in the /etc/group file because the GID in the /etc/passwd entry complements the secondary group membership defined in the /etc/group file.
Secondary—If a user’s name appears in the /etc/group entry for a group, the user is a member of that group, and she gets access to the objects that group is the group owner of. The last field of each entry of the /etc/group file stores the secondary member list.
Groups are assigned numbers, just as user accounts are. The group numbers are called GIDs (Group IDs). A few important GIDs:
0—The root group; anyone who is a member of this group has access to resources restricted to the root account.
1—The bin group is similar to the bin user account.
100—The users group is where you can place regular users and then give them access to resources by assigning that group ownership of things that all users should have access to.
Note
On BSD-related systems (recall BSD is a Unix flavor), a user cannot use the su command unless her account is a member of the wheel group, even if she knows the root password. This wheel group feature is not implemented by default on Linux systems, but the group is there for compatibility. Many administrators use the wheel group on Linux to create an “administrator group,” providing special access to commands via the sudo command.
A special situation exists primarily on Red Hat-based systems, when a user account is created without a specific primary group assigned. In this case, the system creates and assigns a group whose GID should match the number of the user’s UID (if that GID is not available, the next incremented number available would be used) and whose group name should be the same as the user account name. This system is called user private group (UPG).
UPG is a security feature. If you have created a user and haven’t assigned her a primary group, the system might assign her the users group as a primary group. This is a security risk because this user might be a contractor or an auditor and by default should not have access to the users group’s resources.
However, UPG can also cause security issues. Because the user is the only member of this private group, this makes it difficult for the user to share file objects with others. Users are forced to share their files with everyone (the others permission set) to be able to share files with one other person.
Debian-based systems are different in that they don’t use UPG, but rather assign new accounts to the users (100) group by default.
In reality, both systems pose security issues. The best solution is to create groups for people who need to share files and place the appropriate users in the correct groups. This requires more work for the administrator but leads to better security.
Group Entries in /etc/group
The entries in the /etc/group file are much simpler and shorter than the ones in the password file. Group files consist of the following fields:
users:x:100:ross,snuffy
The entries in a group file are
users—The name of the group, which should be eight or fewer characters and lowercase.
x—Like user passwords, the group passwords are kept in a different file. The group passwords are in /etc/gshadow. Note: while understanding this file can be useful, it is not an exam objective and is not be covered in this book.
GID—This is the system’s number for this group and is resolved (translated) to the group name for user viewing convenience.
ross,snuffy—Users in the group are listed one after the other separated with a comma (,); no spaces should occur. This defines secondary group membership.
Group Passwords
Users can have only a single primary group; if they need to create an object that has to be assigned to another group, the user can use the chgrp command. For a single file, this is easy, but if the user wants to create a bunch of files owned by a different group, this technique can be tedious.
Another option is for users to temporarily change their primary group with the newgrp command. For example:
newgrp users
The newgrp command doesn’t alter the /etc/passwd file or the /etc/group file; it opens a new shell with a different primary group. By default, a user can use the newgrp command to temporarily change her primary group to any group she is a member of. After creating the necessary files, the user can return to the shell that has the default primary group by executing the exit command. Note that users can change only to groups that they are a secondary member of.
A password can be assigned to the group with the gpasswd command, but there is only one password and you have to give it to every user who needs to use this functionality. Once a group is assigned a password, users need to use the password to execute the newgrp command, even if the user is a member of that group.
Adding Users and Groups
Although you can edit the /etc/passwd and /etc/group files directly, this can lead to serious problems if you make any errors in these files. It is much safer to use the commands provided.
Adding Users with useradd
The useradd command is used to create new user accounts. To add a user with the default values (default primary GID, default home directory, and so on), execute the following command:
useradd snuffy
Currently, on a Red Hat machine, this command performs several operations including
Creates the user snuffy with the next available UID (typically next available above 500)
Creates a group with the same group name and GID as the username and UID
Sets the user’s primary GID to the newly created group
Creates a home directory for the user under the /home directory and with the same name as the username (/home/snuffy in this case)
Copies the contents of the /etc/skel directory into the new user’s home directory and gives the new user ownership of the copied files and directories
Currently, on a Debian machine, the command useradd snuffy creates the user snuffy with the next available UID, the GID set to the users (GID = 100) group, and no home directory is created.
To set up the user on the Debian system with a specified home directory, you have to specify the -m and –d options. To copy the contents of the /etc/skel directory into the user’s home directory, use the –k option. To specify the primary group, use the –g option. The –u option can be used to specify the UID for the new user. Note that all these options can also be used on a Red Hat system, but often they are omitted in favor of default values. For example:
useradd -m -d /home/snuffy -k /etc/skel -g 100 –u 1025 snuffy
This creates the user with all the specified information. On a Red Hat machine the /bin/bash shell is auto-supplied, whereas on a Debian machine the shell is blank by default, causing the system to assume the /bin/sh shell (which is a symbolic link to /bin/bash). On both systems this value can be defined with the -s option.
Other important useradd options are as follows:
-D—Executing the useradd command with this option displays the defaults defined in the /etc/default/useradd file. This option can also be used to modify the defaults.
-e—This sets an expiration date on the account; after that date the account is disabled.
-G—This sets secondary group membership at the account creation, something that is often done after creating the account by using the usermod command.
-f—This is the number of days after the password has reached its maximum life that the user can still log in (if the user changes his password during the login process). Setting the maximum and minimum password values is discussed in a later section.
-o—This allows the creation of a user with a nonunique UID. This is very dangerous and not recommended.
-s—The full path and filename of the user’s login shell must follow the -s option.
The useradd Defaults
On Red Hat-based systems, the useradd defaults are defined in the /etc/default/useradd file and can be altered with the use of the -D option for the useradd command. For example, to change the default shell from /bin/bash to /bin/tcsh, execute the following command:
useradd -D -s /bin/tcsh
Debian-based systems also use this file. For example, executing the useradd -D -g 10 command sets the default group to be the wheel group (GID=10) when you add a user on Debian.
skel Templates
When you use the useradd command and the -m and –d options, a home directory is created for the user. By default, the new home directory is a copy of the /etc/skel directory and its contents.
For example, useradd –m –d /home/snuffy snuffy creates the home directory /home/snuffy. This home directory is copied by default from the /etc/skel directory, and the ownership is changed to match the new user (as demonstrated in Example 15-1).
Example 15-1 Demonstration of /etc/skel
[root@server1 ~]# ls -la /etc/skel
total 24
drwxr-xr-x. 3 root root 74 May 9 18:15 .
drwxr-xr-x. 154 root root 8192 May 28 20:18 ..
-rw-r--r--. 1 root root 18 Mar 5 14:06 .bash_logout
-rw-r--r--. 1 root root 193 Mar 5 14:06 .bash_profile
-rw-r--r--. 1 root root 231 Mar 5 14:06 .bashrc
drwxr-xr-x. 4 root root 37 May 9 18:15 .mozilla
[root@server1 ~]# useradd tim
[root@server1 ~]# ls -la /home/tim
total 12
drwx------. 3 tim tim 74 May 28 21:25 .
drwxr-xr-x. 4 root root 30 May 28 21:25 ..
-rw-r--r--. 1 tim tim 18 Mar 5 14:06 .bash_logout
-rw-r--r--. 1 tim tim 193 Mar 5 14:06 .bash_profile
-rw-r--r--. 1 tim tim 231 Mar 5 14:06 .bashrc
drwxr-xr-x. 4 tim tim 37 May 9 18:15 .mozilla
You can put just about anything in a new user’s home directory by placing files or directories in the /etc/skel directory. It’s even more elegant to create a set of /etc/skel_XXX directories to make creating certain groups of users easier. For example, to have a special home directory structure for users in the payroll department, you might use the following steps:
1. Copy the /etc/skel directory to a new directory named /etc/skel_payroll_staff.
2. Populate the /etc/skel_payroll_staff with the files and directories that you want users who are in the payroll department to have.
3. Next time you create a user from the payroll department, use the following syntax to specify a the correct skel template directory:
useradd -k /etc/skel_payroll_staff bob
Adding Groups with groupadd
The groupadd command is much simpler than the useradd command, with fewer options and shorter command lines. To add a group named somegroup with the defaults for new groups, type the following:
groupadd somegroup
The previous command creates a group with a GID determined by using the “next available” number above 500. The result should be an entry like the following in the /etc/group file:
somegroup:x:516:
Note that no users are added to the group (the last field is empty). The usermod command discussed in the next section is used to add users to existing groups.
To add a group with a particular GID, execute a command like the following:
groupadd -g 1492 somegroup
Modifying Users and Groups
Creating users and groups is one thing, but being able to make them fit a changing system environment is another. Typically, you add and remove users from secondary groups, locking and unlocking accounts, and even changing a password expiration now and then.
Modifying User Accounts with usermod
To modify a user account with the usermod command, you need to decide which of the following options is needed:
-c—The new description for the user; this modifies the GECOS field in the /etc/passwd file.
-d—Changes the user’s new home directory. If there are files in this new home directory, you need to also change the user ownership of these files.
-e—Changes the date the user account expires and is disabled.
-f—Changes the number of inactive days. When a user account is locked out because the maximum password time frame has been exceeded, the user can have a grace period in which she can still log in as long as she changes her password during the login process. More discussion on this occurs when maximum and minimum password aging is discussed.
-g—Changes the primary group for the user; either GID or group name can be specified. Warning: This changes which file objects the user has access to.
-G—Changes the user’s secondary groups. This is a single value or a list of comma-separated values of groups the user is to be a secondary member of. Important note: Be sure to include all groups, including groups that the user is already a secondary member of. This command replaces all secondary group memberships with the argument provided to the –G option.
-s—Changes the path to the user’s login shell.
-u—Changes the user’s UID. Warning: While this changes the UID ownership of files in the user’s home directory to match the new UID, other files on the system will not automatically be changed!
-L—This locks a user’s account by altering the /etc/shadow file and prefixing the current encrypted password with an exclamation point (!).
-U—This removes the lock on the user’s account by removing the exclamation point (!) from the front of the encrypted password in the /etc/shadow file.
Note
Another way to lock and unlock the user’s account is to use the passwd command and its -l and -u options to accomplish the locking and unlocking.
Modifying Groups with groupmod
The groupmod command has fewer options than the usermod command, and there are only a few reasons to use the command. It’s primarily for altering the group’s name and GID. To modify a group’s GID, execute the following command:
groupmod -g 101 users
Think twice before altering the GID of a group because you could orphan a lot of important files if you do. Remember: Files and directories are not owned by usernames and group names, but rather UIDs and GIDs. If you modify a group’s GID, files previously owned by that GID now no longer have a group name associated with the file, as demonstrated in Example 15-2.
Example 15-2 Demonstration of Changing GID
[root@server1 tmp]# ls -l sample
-rw-r--r--. 1 root test 0 May 28 20:17 sample
[root@server1 tmp]# grep test /etc/group
test:x:1001:
[root@server1 tmp]# groupmod -g 2000 test
[root@server1 tmp]# grep test /etc/group
test:x:2000:
[root@server1 tmp]# ls -l sample
-rw-r--r--. 1 root 1001 0 May 28 20:17 sample
You should also look in the /etc/passwd file to see which users’ primary groups will be affected when you change a group. Do not attempt to change the GID of a group that has a user member currently logged in. Finally, be aware that on some systems, removing or orphaning the primary group of a user defaults to the staff (50) group.
Removing Users and Groups
Removing users and groups isn’t difficult, but several options need attention. Removing accounts from the system isn’t like on a Windows machine, which uses SIDs or security IDs, which are numerically unique and cannot be re-created easily. Linux accounts can be re-created easily (unless you delete the user’s home directory, which could only be recovered from a backup). Remember that Linux uses tables of static UIDs and GIDs, not SIDs.
Removing Users
If a user leaves the company, you are faced with either deleting the user account and leaving the user’s home directory on the system (perhaps for his replacement) or purging the system of the user by removing his account and home directory in one step.
Removing a user without affecting his home directory is accomplished by executing the following command:
userdel snuffy
To remove the user along with his home directory (the one configured in the /etc/passwd entry), you execute the following command:
userdel -r snuffy
Note
If the user also has mail on this system, the userdel –r command also deletes the user’s mail file. However, other files on the system owned by this user will not be deleted. Those files will be owned by just the UID, not the name, of this user. Additionally, if you create a new user with the same UID as the old user, the new user would be the owner of these files.
You cannot delete a currently logged-in user, so you must find out why he is still logged on. On some Linux systems, if the user is logged in and you attempt to delete that account, you receive an error message like the following:
userdel: user tim is currently used by process 17098
If you don’t receive this sort of message, you can execute the ps command to determine the login shell’s PID. Before you kill this user’s login shell, use the usermod -L command to lock the account; then use kill -9 PID to log the user off the system. For example, to log off the tim user and delete the account, execute the following commands:
usermod –L tim
kill -9 17098
userdel -r
One reason you shouldn’t just remove a user’s home directory is that usually either important files or important evidence (perhaps of wrongdoing on the user’s part) exists in that directory. If you are planning to replace the user, consider keeping the directory and just delete the user account. This leaves the home directory and its contents with only a UID where the username was:
drwxr-sr-x 2 1002 staff 4096 Mar 18 07:17 snuffy
This is actually not a bad thing to see because it is a visual clue to you that the user who owned this home directory was deleted. However, because the home directory still belongs to the UID 1002 and the old user’s login name was set as the directory name, you have everything you need to re-create the user or set up a new user. For example, the following uses snuffy’s old home directory for the new sarah account:
mv /home/snuffy /home/sarah
useradd –u 1002 –d /hom/sarah sarah
Removing Groups
Before you delete a group, consider checking the following:
Confirm that the group has no secondary members.
Confirm that the group isn’t a primary group for any user account.
Use the find command to find all files owned by the group. After you find them all, change the group ownership of all these files to another group.
To delete a group, type the following:
groupdel grpname
Note
The majority of the questions on the exam focus on the useradd, usermod, and userdel commands. There isn’t much to ask about the group commands, but there might be a couple of questions about them in the fill-in-the-blank questions just to see whether you’re paying attention.
The Shadow Suite
Another important piece of your Linux machine with regard to security is the Shadow Suite. The Shadow Suite is a set of authentication tools and utilities that insinuates itself into the mix of the /etc/passwd file and user accounts. Without the use of the shadow tools, your encrypted passwords would be exposed to anyone who wants to see them because they would be in the world-readable /etc/passwd file in field #2. The Shadow Suite also provides password aging properties that don’t exist without this Suite. All this is accomplished by storing this data in another file: the /etc/shadow file.
Encrypted Passwords and Shadow Fields
The following is an example of an entry from the /etc/passwd file on a system that doesn’t use the Shadow Suite:
snuffy:$1$vEEOvj1b$GlzLuD9F..DjlQr/WXcJv1:501:10::/home/snuffy:/bin/sh
As you can see, an encrypted string appears in the second field. Unfortunately, all users can view this file, making this a potential security risk. In the next example, the /etc/passwd entry is shown on a system with the Shadow Suite enabled; note that the encrypted string is replaced with an “x”:
snuffy:x:501:10::/home/snuffy:/bin/sh
When the Shadow Suite is installed, the system stores encrypted passwords in the /etc/shadow file for user accounts and the /etc/gshadow file for group accounts. The fields in the /etc/shadow file contain the user’s account password and password aging information. The following is an example of a shadow file entry:
snuffy:$1$vEEOvj1b$GlzLuD9F..DjlQr/WXcJv1:16263:0:99999:7:30:17000:
The fields in the /etc/shadow file are
snuffy—Login name: The user’s login name
$1$vEEOvj1b$GlzLuD9F..DjlQr/WXcJv1—Password: The user’s encrypted password
16263—Last Change: The days since January 1, 1970, that have elapsed since the password was last changed
0—Minimum: The days that must elapse before the password can be changed (0 effectively always allows immediate changes)
99999—Maximum: The days before the password must be changed (99999 effectively disables the need to change the password as this is over 273 years)
7—Warning: The number of days before the password expires due to the Maximum field when the user will be warned
30—Inactive: The number of days after the account expires due to the Maximum field in which the user could still log in if the password is changed during login
17000—Expiration date: The number of days from January 1, 1970, and the day the account will expire on
Note
The last field in the file is reserved for future use and is not tested or much talked about.
Some of the fields of the /etc/shadow file are tricky. Consider the following:
julia:$1$vEEOvj1b$GlzLuD9F..DjlQr/WXcJv1:16263:5:90:7:30::
The julia account does not have an expiration date (Expiration field is empty); however this user is required to change her password every 90 days (Maximum field is 90). Seven days before the 90-day time frame is up, the user will receive a warning when she logs in (Warning field is 7). If she does not heed this warning, her account will be locked out on day 91. She can still log in for up to 30 days after her account is locked (Inactive field is 30), provided that she creates a new password during the login process. Finally, after changing her password, she cannot change her password again for at least 5 days (Minimum field is 5) to prevent her from just switching back to her original password.
Note
The password aging provided by the Shadow Suite is far from perfect. Pluggable authentication modules (PAM) provide much richer and more powerful password aging features.
shadow File Permissions
The permissions on the /etc/shadow file are important and may appear on the exam. Because the /etc/shadow file isn’t world-readable, and only the system updates it, your passwords are much safer than without shadow installed.
The /etc/shadow file permissions are prominently featured on the exam, as are the permissions for the /etc/passwd file. Here is a listing of the files and permissions on both Red Hat and Debian:
/etc/passwd"
Red Hat = -rw-r--r-- (644)
Debian = -rw-r--r-- (644)
/etc/shadow"
Red Hat = -r-------- (400)
Debian = rw-r----- (640)
As mentioned, these files and their permissions appear on the exams. It’s important that you remember that Red Hat has a stricter permission setup than Debian.
Note
Take note of the security permissions on the shadow file of your various test systems. You’ll find small but important variations. Some systems use ------- and some use r------; make sure to note which is which. The /etc/passwd file is essentially open and readable by anyone, even those not on the system. The important and private encrypted passwords are in the /etc/shadow file.The /etc/gshadow file mentioned previously is also part of the Shadow Suite. However, this file is not an exam objective.
Changing Accounts
Users’ passwords are typically initially set to some easily remembered value by the root user when the account is created and then the user is told to change her password immediately.
To change the root password, execute the following command when you are logged in as the root user:
passwd
This prompts you for a password that must be entered twice for verification. If you are executing this command as a normal user, the user’s current password is required before the new password will be accepted. This is to avoid a situation where you walk away from your system and someone quickly tries to change your password.
If you’re changing another user’s password, like the snuffy user, you would execute the following when you are logged in as the root user:
passwd snuffy
Note
It’s important to remember who you are logged in as and what you type on the command line when changing a password. I’ve seen many a sysadmin change her own password instead of a user’s because she was in a big hurry!
Aging Passwords
Users’ passwords need to be changed frequently enough so that attackers don’t have enough time to guess them. Most users want to come to work, get paid, and go home; system security is of much lower importance than convenience.
To age the passwords properly, use the chage command. The syntax for the chage command is
chage -option value username
The command acts on fields in the /etc/shadow file, with the following options:
-m—Changes the Minimum value, or how long after a password is changed that the user must wait until it can be changed again.
-M—Changes the Maximum value, which is the maximum number of days that can go by before the user must change the password.
-d—Changes the Last Change value, which is the number of days since January 1, 1970, that the password was last changed. This is rarely modified directly; when a password is changed with the passwd command, this value is automatically updated.
-E—Changes the Expiration value, which is the number of days since January 1, 1970, that represents the day the user’s account will be disabled. The format used is YYYY-MM-DD.
-I—Changes the Inactive value, or the number of days of inactivity (no logins) after the account has reached the Maximum limit before the user account is locked, requiring root attention to reenable. Setting this to 0 disables the feature.
-W—Changes the Warning value, or the number of days before the user must change her password. This warning is only provided when the user logs in to the system.
Thankfully, you don’t have to memorize these values, except for potential exam questions. Just execute the chage username command as the root user and the command prompts you interactively for each value that can be configured for the specified user.
Users can use the -l option to view their own information, or the root user can view another user’s information with this option:
chage -l snuffy
This produces the following output:
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Mar 19, 2014
Password Expires: Never
Password Inactive: Never
Account Expires: Never
The passwd utility includes some of the previous options, such as these:
-d—Disables a user account by removing its password
-n—Sets the minimum password lifetime in days
-x—Sets the maximum password lifetime in days
-w—Sets the warning number of days before the password expires
-i—Sets the number of days an account with an expired password can be inactive before it’s locked
-S—Shows the user password information, such as what encryption is used and whether a password is set
User Variables
Next, you learn how to place certain limitations on a user’s account. If you want a user to be unable to create objects over a certain size or use too many system resources, you could configure the ulimit settings for that user. The ulimit command accepts many options, including the following:
-c—Limits the size of core (crash dump) files
-d—Limits the size of the user’s process data
-f—Limits the maximum size of files created in the shell
-n—Limits the number of open file descriptors or open files allowed
-t—Limits the amount of CPU time allowed to the user (expressed in seconds)
-u—Limits the number of processes that a given user can run
-v—Limits the maximum amount of virtual memory available to the shell
To check a user’s ulimit settings, use this command:
ulimit –a
Note
Remember that making these limits more permanent requires editing one of the user’s configuration files (.bashrc or .profile) or the systemwide configuration files (/etc/bashrc or /etc/profile).
Summary
In this chapter you learned the concept of user and group accounts. You learned in which files account information is stored as well as how to create, modify, and delete accounts.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 21, “Final Preparation,” and the practice exams on the DVD.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 15-2 lists a reference of these key topics and the page numbers on which each is found.
Table 15-2 Key Topics for Chapter 15
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
UID
GID
GECOS
PAM
primary group
secondary group
UPG
user private group
skel template
Shadow Suite
ulimit
Review Questions
The answers to these review questions are in Appendix A.
1. Which field in the /etc/shadow file sets the number of warning days before the user’s password expires? Fill in just the numeral of this field in the blank below:
_________________________________________________________
2. If you saw the following output of the ls -l command, what would it indicate?
drwxr-sr-x 2 1002 staff 4096 Mar 18 07:17 snuffy
a. The account was deleted, but not the user’s home directory.
b. The file is not owned by any account.
c. The /etc/passwd file is corrupt.
d. The user’s group is incorrect.
3. If you created 10 accounts beginning with the UID of 501 and then deleted 501 and 504, what would the UID of the next user you create be by default? Write your answer in the blank below:
_________________________________________________________
4. Which directory is copied by default to a newly created user’s home directory when the -m and –d options are used with the useradd command? Fill in the full path and name of the directory in the blank below:
_________________________________________________________
5. Which command is used to set the password expiration, warning, and other /etc/shadow file field information interactively?
a. passwd
b. chpass
c. vipw
d. chage
6. Which command allows a user to open a shell with a different primary group? Fill in the blank below with just the name of the command:
_________________________________________________________
7. What are the default permissions for the Debian and Red Hat /etc/passwd files? Fill in the blank below with the three numerals that represent the octal value for the permissions:
_________________________________________________________
8. Which command can be used by regular users to display settings for features like the maximum allowable size of files allowed for the user’s account?
a. umask
b. dmesg
c. ulimit
d. perms