Understanding Account Features

 Most account features are defined in the /etc/passwd file, which consists of colon-delimited lines, with each line (or record) defining a single account. An entry might resemble the following:

rich:x:1001:1001:Richard Blum:/home/rich:/bin/bash

The information contained in the fields of this record includes the following:

Username  An account’s username is its most relevant feature. Most Linux account usernames consist of lowercase letters, and occasionally numbers, as in rich or thx1138. Underscores (_) and dashes (-) are also valid characters in some Linux distributions’ usernames.

Password  User accounts are typically protected by a password, which is required to log into the computer. Direct login to most system accounts is disabled, so they lack passwords. (The root account is an important exception on some distributions; it may have a password.) The password field in the /etc/passwd file usually contains an x, which is a code meaning that the password is stored in /etc/shadow, as described shortly.

UID  In reality, the username is just a label that the computer displays to us numerically challenged humans. The computer employs a user identification (UID) number to track accounts. UID numbers begin with 0 (which refers to the root account). In most distributions, user accounts have UID numbers at 1,000 and above, with lower numbers reserved for system accounts.

GID  Accounts are tied to one or more groups, which are similar to accounts in many ways; however, a group is a collection of accounts. One of the primary purposes of groups is to enable users to give certain other users access to their files, while preventing users not in a designated group from accessing them. Each account is tied directly to a primary group via a group ID (GID) number (100 in the preceding example). By including an account in a group’s definition, accounts can be tied to several groups as described in Chapter 13, “Creating Users and Groups.”

Comment Field  The comment field normally holds the user’s full name (Richard Blum in this example), although this field can hold other information instead of or in addition to the user’s name.

Home Directory  User accounts, and some system accounts, have home directories 
(/home/rich in this example). A home directory is an account’s “home base.” Normally, ownership of an account’s home directory belongs to the account. Certain tools and procedures make it easy for users to access their home directories; for instance, the tilde (~) refers to a user’s home directory when used at the start of a filename.

Default Shell  A default shell is associated with every account. In Linux, this shell is normally Bash (/bin/bash), but individual users can change this if they like. Most non-root system accounts set the default shell to /usr/sbin/nologin (or /sbin/nologin) as an added security measure—this program displays a message stating that the account is not available. Using /bin/false works in a similar way, although without the explanatory message.

 You might guess by its name that /etc/passwd holds password information. This 
isn’t normally the case today, although it was many years ago. For historical reasons, 
/etc/passwd must be readable by all users, so storing passwords there, even as a salted and hashed password, is risky.

Passwords today are stored in another file, /etc/shadow, that ordinary users can’t read. This file associates a salted and hashed password, as well as other information, with an account. This information can disable an account after a period of time or if the user doesn’t change the password within a given period of time. A typical /etc/shadow entry looks like this:

rich:$6$E/moFkeT5UnTQ3KqZUoA4Fl2tPUoIc[...]:18114:5:30:14:-1:-1:

The meaning of each colon-delimited field on this line is as follows:

Username  Each line begins with the username. Note that the UID is not used in 
/etc/shadow; the username links entries in this file to those in /etc/passwd.

Password  The password is stored as a salted hash, so it bears no obvious resemblance to the actual password. An asterisk (*) or exclamation mark (!) denotes an account with no password (that is, the account doesn’t accept logins—it’s locked). This is common for accounts used by the system itself.

Last Password Change  The next field (18114 in this example) is the date of the last password change. This date is stored as the number of days since January 1, 1970.

Days Until a Change Is Allowed  The next field (5 in this example) is the number of days before a password change is allowed. This is used to prevent users from changing their passwords (as required) and then changing them right back to the original password.

Days Before a Change Is Required  This field (30 in this example) is the number of days before another password change is required (since the last password change).

Days of Warning Before Password Expiration  If your system is configured to expire passwords, you may set it to warn the user when an expiration date is approaching. A value of 7 is typical. However, 14 days, as shown in the preceding example, may be appropriate if your company’s employees take two-week vacations.

Days Between Expiration and Deactivation  Linux allows a gap between when the account expires and when it is completely deactivated. An expired account either can’t be used or requires that the user change the password immediately after logging in. In either case, its password remains intact. A deactivated account’s password is erased, and the account can’t be used until the system administrator reactivates it. A -1 in this field, as shown in the preceding example, indicates that this feature is disabled.

Expiration Date  This field shows the date on which the account will expire. As with the last password change date, the date is expressed as the number of days since January 1, 1970. A -1 in this field, as shown in the preceding example, indicates that this feature is disabled.

Special Flag  This field is reserved for future use and normally isn’t used or contains a meaningless value. This field is empty in the preceding example.

For fields relating to day counts, typically a value of -1 or 99999 or no value (blank) indicates that the relevant feature has been disabled. The /etc/shadow values are generally best left to modification through commands such as usermod (described in Chapter 13) and chage. Understanding the format of the file enables you to review its contents and note any discrepancies, which could indicate that your system has been compromised.

The /etc/shadow file is usually stored with restrictive permissions, with ownership by root. This fact is critical to the shadow password system’s utility because it keeps non-super users from reading the file and obtaining the password list, even in a salted and hashed form. By contrast, /etc/passwd must be readable by ordinary users and usually has less restrictive permissions.

It’s important to realize that an account isn’t a single entity like a program binary file. Account information is scattered across several configuration files, such as /etc/passwd, 
/etc/shadow, /etc/group, and possibly in other configuration files that refer to accounts. User files reside in the user’s home directory and perhaps elsewhere. Thus, managing accounts can require doing more than just maintaining a file or two. For this reason, various utilities exist to help create, manage, and delete accounts, as described in the rest of this chapter and in Chapter 13.

Identifying Accounts

One way to identify user accounts is to use a GUI tool for account management. Such tools vary from one distribution to another. One example is the Users and Groups account tool on a Linux Mint system. You can reach this tool by clicking Menu in the main window and then typing user in the search box, as shown in Figure 12.1.

Accessing this option produces a window similar to the one shown in Figure 12.2 but only if you have super user privileges and provide the appropriate password. This tool shows only user accounts, not system accounts. It enables changing a few features, such as a user’s password, by clicking them, but its usefulness as an account management tool is limited.

You can identify all of a computer’s accounts by viewing the /etc/passwd file’s contents with cat or less. Doing so will reveal all accounts, including both system and user accounts.

Alternatively, if you’re searching for information on a specific account, you can use grep to find it in /etc/passwd, as in grep rich /etc/passwd to find information on any account that’s tied to a user with the username rich. (This specific example assumes that the string rich appears in the passwd file, of course.)

An alternative that’s similar to perusing /etc/passwd is to type getent passwd. The getent command retrieves entries from certain administrative databases, including the 
/etc/passwd file. In most cases, typing getent passwd produces results that are identical to typing cat /etc/passwd; however, sometimes the two aren’t identical. The 
/etc/passwd file defines only local user accounts. It’s possible to configure Linux to use 
a network account database to define some or all of its accounts. If you use such a configuration, typing getent passwd returns both local accounts and accounts defined on the network server.

Understanding Groups

 As noted earlier, groups are collections of accounts that are defined in the /etc/group file. Like /etc/passwd, the /etc/group file contains colon-delimited lines (records), each defining a single group. An example looks like this:

users:x:100:games,christine

The fields in /etc/group are as follows:

Group Name  The first field, users in the preceding example, is the name of the group. You use it with most commands that access or manipulate group data.

Password  Groups, like users, can have passwords. A value of x means that the password is defined elsewhere (but may be disabled), and an empty password field means that the group has no password.

GID  Linux uses GID values, like UID values, internally. Translation to and from group names is done by the system for the benefit of users and administrators.

User List  You can specify users who belong to the group in a comma-delimited list at the end of the /etc/group record.

It’s important to recognize that users can be identified as members of a group in either of two ways:

By Specifying the Group’s GID in Users’ Individual /etc/passwd Entries  Because 
/etc/passwd has room for only one GID value, only one group can be defined in this way. This is the user’s primary (or default) group.

By Specifying Usernames in the User List in the /etc/group File  A single user can appear multiple times in /etc/group, and a single group can have multiple users associated with it in this way. If a user is associated with a group in this way but not via the user’s 
/etc/passwd entry, this group association is secondary.

When you create new files, those files will be associated with your current group. When you log in, your current group is set to your primary group. If you want to create files that are associated with another group to which you belong, you can use the newgrp command, as follows:

$ newgrp project1

This command makes project1 your current group, so that the files you create will be associated with that group. Group ownership of files is important in file security, which is described in more detail in Chapter 14.

Discovering Your Own Identity

If you maintain multiple accounts for yourself and you don’t recall which one you used to log in, you might become confused about your current status. In such a case, the whoami command can come in handy. It displays your current user ID:

$ whoami

christine

 This example reveals that the current account is christine. If you need more information, you can use the id utility:

$ id

uid=1002(christine) gid=100(users) groups=100(users)[...]

This example shows information on both users and groups:

• Your User ID and Username: uid=1002(christine) in this example
• Your Current Group: gid=100(users) in this example
• All Your Group Memberships: the entries following groups= in this example

The id command displays both the numeric UID and GID values and potentially the associated names. The current group is the one that’s active, either by default or because you used the newgrp command.

You can limit id’s output by specifying various options, as summarized in Table 12.1. In addition, you can specify a username, as in id rich, to obtain information on that user rather than on yourself.

Learning Who’s Online

Linux permits multiple users to access the computer simultaneously. Most often, this is done by means of remote access servers such as the Secure Shell (SSH); however, you can use Linux’s virtual terminal (VT) feature to log in multiple times with a single keyboard and monitor. Sometimes, you might want to know who is using the computer. You might do this before shutting down the computer, for instance, to ensure that you don’t inconvenience another user.

 To learn who is online, you can use a command known as who:

$ who

christine tty7         2019-08-06 10:14 (:0)
steph    tty2         2019-08-06 10:57
rich     pts/0        2019-08-06 10:56 (192.168.0.102)
devon    tty3         2019-08-06 10:57
ken      tty4         2019-08-06 10:57
$

This example shows five logins—christine, steph, rich, devon, and ken. Information provided in the default output includes the following:

Username  The first column of who’s output shows the username.

Terminal Identifier  The second column of who’s output shows a code associated with the terminal. In this example, christine’s first login shows tty7 and it is a local GUI login, but some distributions use the 0 as a GUI identifier. The remaining logins all have terminal identifiers of the form pts/ # or tty#, indicating text sessions. A text session can be a terminal launched in a GUI, a text-mode console login, or a remote login via SSH or some other protocol.

Login Date and Time  who displays the date and time of each login. You can see that christine’s session began several minutes before steph logged in.

Remote Host  The final column of who’s output, if present, shows the login source. Console logins (including both text-mode and GUI-based logins) don’t include a source. A source of the form # or # . # or : # often indicates a terminal opened in a GUI, such as in christine’s source: (:0). A hostname or IP address, as in rich’s session, indicates remote access from the specified computer.

You can obtain additional information, most of which is obscure or specialized, by passing options to who. One that’s more likely than others to be useful is --count (or -q), which produces a more compact summary of the data:

$ who -q

christine steph rich devon ken
# users=5
$

This output includes just the usernames and a line specifying the total number of sessions. Notice that the users number counts one user with multiple logins multiple times.

Similar to the whoami command but showing more information, passing the am i 
arguments to the who command displays data only for your current user ID:

$ who am i

rich     pts/0        2019-08-06 10:56 (192.168.0.102)
$

In this example, the current user account is rich, who is logged into the pts/0 terminal session. For information on additional who options and arguments, consult its man page.

 An alternative to who is w, which is similar to who but produces somewhat more verbose output:

$ w

 11:17:26 up  1:10,  5 users,  load average: 0.00, 0.03, 0.04
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
christin tty7     :0               10:14    1:09m 17.12s  0.64s cinnamon[...]
steph    tty2                      10:57    4:30   0.21s  0.16s -bash
rich     pts/0    192.168.0.102    10:56    1.00s  0.20s  0.00s w
devon    tty3                      10:57   20:05   0.21s  0.15s -bash
ken      tty4                      10:57   19:58   0.23s  0.16s -bash
$

As you can see, w displays much of the same information as who, including the terminal identifier (TTY) and login time (in a different format). In addition, w displays further information:

• The session’s idle time tells you how long it’s been since the user has interacted with this session. This information can help you identify sessions that the user may have abandoned.
• The JCPU column identifies the total amount of CPU time associated with the session. This can be useful debugging information if the computer has become sluggish because of out-of-control processes.
• The PCPU column identifies the total amount of CPU time associated with the current process running in the session. Again, this information can help you track down 
out-of-control processes.
• The WHAT column tells you what program the session is running.

Some configurations also display a FROM column, which shows a remote hostname. Using the -f option toggles this option on or off. A few other options can eliminate or modify w’s output. Consult the program’s man page for details.

Understanding User Types

 Most people use computers to do ordinary day-to-day computer tasks—browse the web, write letters, manage a music collection, and so on. These activities are known collectively as user tasks, and they don’t require special privileges. As just noted, a Linux computer can have many user accounts, and the users can use the computer from these user accounts (also known as unprivileged accounts, unprivileged users, or standard users) to perform such user tasks.

 The root account exists to enable you to perform administrative tasks. These tasks include installing new software, preparing a new disk for use in the computer, and managing ordinary user accounts. Such tasks require access to system files that ordinary users do not need to modify or even read.

To facilitate performing these tasks, root can read and write every file on the computer. Since Linux relies on files to store system settings, this effectively gives root the power to change any detail of the OS’s operation, which is the point of having a super user account. If the computer is a workstation that’s used by just one individual, you may wonder why the distinction between root and the user account is necessary. The explanation is that the power of the root account can lead to accidental damage. For instance, take the rm command. If you mistype an rm command as an ordinary user, you can accidentally delete your own files but not system files. Make the same mistake as root, however, and you can delete system files, perhaps making the computer unbootable. Therefore, you should be cautious when using the root account (or not use it at all), a topic covered more thoroughly in the upcoming “Using root Privileges Safely” section.

Acquiring root Privileges

When you need to perform a command-line task that requires root privileges, you can do so in any of three ways:

Log In as root  You can log in directly as root at a text-mode shell or by using a remote login tool such as SSH. You can even log into GUI mode as root on some Linux distributions. Some distributions don’t allow root to log in directly by default because it’s dangerous.

 Use su  The su command enables you to change your identity within a shell. Type 
 su username to change your identity to that of the specified username. If you omit 
 username, root is assumed, so typing su enables you effectively to become root.

You must, however, know the password for the target account (root or otherwise) for this command to work. After you acquire root privileges in this way, you can type as many commands as root as you like. When you’re done, type exit to relinquish your super user status.

You can also use su to run a single command as root. Use the -c option, as in 
 su -c command to run command as root.

If you use a dash (-) within the command, as in su - or su - luke, the program opens a login session that runs the target user’s login scripts. This can be important because these scripts often set environment variables such as $PATH that can be important for that user.

 Use sudo  The sudo command is similar to su, but it works for just one command at a time, which you type after sudo, similar to using su -c. For instance, typing sudo cat 
/etc/shadow enables you to see the contents of the /etc/shadow file, which is not readable by ordinary users. You must type either your own password or the root password, depending on the sudo configuration, when you use this program. (When using su -c, you must always type the root password.) The next command you type will be executed using your ordinary account privileges. Some distributions, such as Ubuntu and Fedora, rely heavily on sudo and don’t permit direct root logins by default.

Many modern distributions do not let you log into the root account. However, if you can acquire root privileges by logging in directly as root or by using su -, your shell prompt will change:

[rey@jakku ~]$  su -

Password:
[root@jakku ~]#

In this example, the username has changed from rey to root and the last character of the prompt has changed from a dollar sign ($) to a hash mark (#). Because just the last prompt character was used for most examples printed on their own lines in this book, such examples implicitly specify whether a command requires root privileges by the prompt used. For instance, consider accessing the /etc/shadow file mentioned earlier:

# cat /etc/shadow

The use of the hash mark prompt indicates that you must type this command using root privileges.

Some of this book’s chapters describe both GUI and text-mode methods of system administration. How, then, can you administer Linux in GUI mode if you must use the text-mode sudo command to acquire root privileges? Most distributions allow you to launch administrative tools from the computer’s desktop menus, and the GUI tools will then prompt you for the super user password when administrative privileges are needed, as shown in Figure 12.3. If you type the password correctly, the program will continue. The result is similar to that of launching the program from a shell using sudo.

Using root Privileges Safely

As already described, root power is dangerous. You could accidentally wipe out critical application files and cause hours of downtime. Imagine what would happen if you mistakenly corrupted an important configuration file or destroyed a set of important backups. Everyone makes mistakes—unfortunately, some mistakes can be absolutely disastrous for a company.

Imagine intruders gaining root access to your computer: unintended changes to configuration files, damage to some (even if not all) of the computer’s system files, and changes to ownership or permissions on ordinary user files, rendering them inaccessible to their true owners. You should take the following precautions whenever you need root access:

• Ask yourself if you really need root access. Sometimes there’s a way to achieve a goal without super user privileges or by using those privileges in a more limited way than you’d originally planned. For instance, you might find that only root can write to a removable disk. Such a problem can usually be overcome by adjusting permissions on the disk in one way or another, thus limiting the use of root.
• Before pressing the Enter key after typing any command as root (or clicking any confirmation button in a GUI program running as root), take your hands off the keyboard and mouse, look over the command, and verify that it’s correct in every respect. A simple typo can cause a world of pain.
• Never run a suspicious program as root. On multiuser systems, unscrupulous users can try to trick administrators into running programs that will do nasty things or give the attacker root privileges. Programs downloaded from random Internet sites could in principle be designed to compromise your security, and such programs are much more dangerous when run as root.

• Use root privileges for as brief a period as possible. If you need to type just one or two commands as root, do so and then type exit in the root shell to log out or return to your normal privileges. Better yet, use sudo to run the commands. It’s easy to overlook the fact that you’re using a root shell and therefore type commands as root that don’t need that privilege. Every command typed as root is a risk.
• Never leave a root shell accessible to others. If you’re performing root maintenance tasks and are called away, type exit in your root shell before leaving the computer.
• Be careful with the root password. Don’t share the password with others, and be ­cautious about typing it in a public area or when others might be looking over your shoulder. If you’re using Linux professionally, your employer may have guidelines 
concerning who may have root access to a computer. Learn those rules and obey them! Be sure to select a strong root password, too.

Following these rules of thumb can help keep you from damaging your computer or giving somebody else root access to the computer.