Chapter 13
Managing Users
System administrators would have a boring, but much easier, life without users. In reality, having a system with absolutely no users is impossible, so learning how to effectively manage and administer your users as they work with your system is important. Whether you are creating a single user account or modifying a group that holds hundreds of user accounts, the fundamentals of user administration are the same.
User management and administration includes allocating and managing /home directories, putting in place good password policies, and applying effective security policies that include things such as disk quotas and file and directory access permissions. This chapter covers all these areas as well as some of the different types of users that you are likely to find on a typical Linux system.
User Accounts
You normally find three types of users on Linux systems: the super user, the day-to-day user, and the system user. Each type is essential to the smooth running of your system. Learning the differences between the three is essential if you are to work efficiently and safely within your Linux environment.
All users who access your system must have accounts on the system. Ubuntu uses the /etc/passwd file to store information on the user accounts that are present on the system. All users, regardless of their type, have a one-line entry in this file that contains their username (typically used for logging in to the system), an encrypted field for the password (which contains an X to indicate that a password is present), a user ID (commonly referred to as the UID), and a group ID (commonly referred to as the GID). The last two fields show the location of the /home directory (usually /home/username) and the default shell for the user (/bin/bash is the default for new users). There is also a field called GECOS that uses a comma-delimited list to record information about the account or the user; most often when this field is used, it records the user’s full name and contact information.
Note
Although the Password field contains an X, this doesn’t mean that what you read here is the actual password. All passwords are stored in /etc/shadow in an encrypted format for safekeeping. Ubuntu automatically refers to this file whenever a password is required. You can read more about this later in the chapter, in the “Shadow Passwords” section.
In keeping with long-standing tradition in UNIX-style operating systems, Ubuntu makes use of the well-established UNIX file ownership and permission system. To start with, everything in these systems is treated as a file, and all files (which can include directories and devices) can be assigned one or more read, write, and execute permissions. These three “flags” can also be assigned as desired to each of three categories: the owner of the file, a member of a group, or anyone else on the system. The security for a file is drawn from these permissions and from file ownership. As the system administrator (also commonly referred to as the super user), it is your responsibility to manage these settings effectively and ensure that the users have proper UIDs and GIDs. Perhaps most importantly, the system administrator can use these file permissions to lock away sensitive files from users who should not have access to them.
The Super User/Root User
No matter how many system administrators there are for a system, there can be only one super user account. The super user account, more commonly referred to as the root user, has total and complete control over all aspects of the system. That account can access any part of the file system; read, change, or delete any file; grant and revoke access to files and directories; and carry out any operation on the system, including destroying it. The root user is unique in that it has a UID of 0 and GID of 0.
Because the root user has supreme power over a system, it’s important that you not work as root all the time because you might inadvertently cause serious damage to your system, perhaps even making it totally unusable. Instead, work as root only when you need to make specific changes to your system that require root privileges. As soon as you’ve finished that work, you can switch back to your normal user account to carry on working.
In Ubuntu, you execute a command with root, or super user, privileges by using the sudo command, like this:
matthew@seymour:~$ sudo apt-get update
You are then prompted for your password, which does not show on the screen as you enter it. After typing in your password, press Enter. Ubuntu then carries out the command (in this case updating information about available software) as if you were running it as root.
The Root User
If you’ve used other Linux distros, you might be a little puzzled by the use of the sudo command because not all distros use it. In short, Ubuntu allows the first user on the system access to full root privileges using the sudo command. It also disables the root account so that no one can actually log in with the username root.
In other Linux distros, you change to the root user by issuing the command su – and then entering the root password when prompted. This lands you at the root prompt, which is shown as a pound sign (#). From here, you can execute any command you want. To get to a root prompt in Ubuntu, you need to execute the command sudo -i, and after you enter your password, you get the prompt so familiar to other Linux distros. When you’ve finished working as root, type exit and press Enter to get back to a normal user prompt ($).
A regular user is someone who logs on to the system to use it for nonadministrative tasks such as word processing or email. These users do not need to make system-wide changes or manage other users. However, they might want to be able to change settings specific to their accounts (for instance, a desktop background). Depending on how much control the system administrator (the root or super user) likes to wield, regular users might not even be able to do that.
The super user grants privileges to regular users using file and directory permissions (as covered in Chapter 10, “Command-Line Beginner’s Class”). For example, if the super user does not want you to change your settings in ~/.profile (the ~ is a shell shortcut representing your /home directory), then as root she can alter the permissions so that you may read from, but not write to, that file.
Caution
Because of the potential for making a catastrophic error as the super user, use your system as a regular user most of the time and use your super user powers only temporarily to do specific administration tasks. This is easier to remember in Ubuntu than in some other distros because the root account is initially disabled, and you must manually choose to use sudo. If you work on a multiuser system, consider this advice an absolute rule; if root were to delete the wrong file or kill the wrong process, the results could be disastrous for the system (and likely the business that owns and operates it). On your home system, you can do as you please. Running as root makes many things easier—but much less safe—and we still do not recommend using it all the time. In any setting, the risks of running as root are significant, and we cannot stress enough how important it is to be careful when working as root.
The third type of user is the system user. The system user is not a person but rather an administrative account that the system uses during day-to-day running of various services. For example, the system user named www-data owns the Apache web server and all the associated files. Only that user and root can have access to these files; no one else can access or make changes to these files. System users do not have a home directory or password, nor do they permit access to the system through a login prompt.
You can find a list of all the users on a system in the /etc/passwd file.
User IDs and Group IDs
A computer is, by its very nature, a number-oriented machine. It identifies users and groups by numbers known as the user ID (UID) and group ID (GID). The alphabetic names display on your screen just for ease of use.
As previously mentioned, the root user is UID 0. Numbers from 1 through 499 and number 65,534 are the system, sometimes called logical users, or pseudo-users. Regular users have UIDs beginning with 1,000; Ubuntu assigns them sequentially, beginning with this number.
With only a few exceptions, the GID is the same as the UID.
Ubuntu creates a private GID for every UID of 1,000 and greater. The system administrator can add other users to a GID or create a totally new group and add users to it. Unlike in Windows NT and some UNIX variants, a group in Ubuntu (or any other Linux distribution) cannot be a member of another group.
File Permissions
There are three types of permissions: read, write, and execute (r, w, x). For any file or directory, permissions are assigned to three categories: user, group, and other. This section focuses on group permissions. First, though, we want to highlight three commands used to change the group, user, or access permissions of a file or directory:
▸ chgrp—Changes the group ownership of a file or directory
▸ chown—Changes the owner of a file or directory
▸ chmod—Changes the access permissions of a file or directory
You can use these commands to reproduce organizational structures and permissions in the real world in your Ubuntu system (see the next section, “Managing Groups”). For example, a human resources department can share health-benefit memos to all company employees by making the files readable (but not writable) by anyone in an accessible directory. Programmers in the company’s research and development section, although able to access each other’s source code files, would not have read or write access to HR pay scale or personnel files—and certainly would not want HR or marketing poking around R&D.
These commands are used to easily manage group and file ownerships and permissions from the command line. It is essential that you know these commands because there are times when you are likely to have only a command-line interface to work with. (There was a time when a well-meaning but fat-fingered system administrator set incorrect permissions on X11, rendering the system incapable of working with a graphical interface. No, we won’t tell that story, but if you press them, most systems administrators have similar tales of woe.)
User Stereotypes
As is the case in many other professions, exaggerated stereotypes have emerged for users and system administrators. Many stereotypes contain elements of truth mixed with generous amounts of hyperbole and humor and serve to assist us in understanding the characteristics of and differences in the stereotyped subjects. The stereotypes of the luser and the BOFH (not-so-nice terms for users and administrators, respectively) serve as cautionary tales describing what behavior is acceptable and unacceptable in the computing community.
Understanding these stereotypes enables you to better define the appropriate and inappropriate roles of system administrators, users, and others. You can find descriptions of these terms on Wikipedia at https://en.wikipedia.org/wiki/Luser and https://en.wikipedia.org/wiki/BOFH.
Managing Groups
Groups can make managing users a lot easier. Instead of having to assign individual permissions to every user, you can use groups to grant or revoke permissions to a large number of users quickly and easily. Setting group permissions enables you to set up workspaces for collaborative working and to control what devices can be used, such as external drives or DVD writers. This approach also represents a secure method of limiting access to system resources to only those users who need them. As an example, the system administrator could put the users matthew, ryan, sandra, holly, debra, and mark in a new group named unleashed. Those users could each create files intended for their group work and chgrp those files to unleashed.
Now, everyone in the unleashed group—but no one else except root—can work with those files. The system administrator would probably create a directory owned by that group so that its members could have an easily accessible place to store those files. The system administrator could also add other users such as chris and shannon to the group and remove existing users when their part of the work is done. The system administrator could make the user matthew the group administrator so that matthew could decide how group membership should be changed. You could also put restrictions on the DVD writer so that only matthew could burn DVDs, thus protecting sensitive material from falling into the wrong hands.
Group Listing
Different UNIX operating systems implement the group concept in various ways. Ubuntu uses a scheme called UPG (user private group) in which the default is that each user is assigned to a group with his or her own name. (The user’s username and group name are identical.) All the groups on a system are listed in /etc/group file.
Here is an example of a portion of the /etc/group file:
matthew@seymour:~$ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:matthew tty:x:5: disk:x:6: mail:x:8: news:x:9: fax:x:21:matthew voice:x:22: cdrom:x:24:matthew floppy:x:25:matthew tape:x:26:matthew www-data:x:33: crontab:x:107: ssh:x:109: admin:x:115:matthew saned:x:116: gdm:x:119: matthew:x:1000: ntp:x:122:
In this example, you see a number of groups, mostly for services (mail, news, and so on) and devices (disk and so on). As previously mentioned, the system services groups allow those services to have ownership and control of their files. For example, adding Postfix to the mail group enables the Postfix application to access mail’s files such that mail can decide about group access to its file. Adding a regular user to a device’s group permits the regular user to use the device with permissions granted by the group owner. Adding user matthew to the group cdrom, for example, allows matthew to use the optical drive device. You learn how to add and remove users from groups in the next section.
Finding Your Groups
You can find which groups your user account belongs to by using the groups command, like this:
matthew@seymour:~$ groups
matthew adm cdrom sudo audio dip plugdev lpadmin sambashare
Add a username after the command to list the groups for that user.
Group Management Tools
Ubuntu provides several command-line tools for managing groups, and it also provides graphical tools for doing so. Most experienced system administrators prefer the command-line tools because they are quick and easy to use, they are always available (even when there is no graphical user interface), and they can be included in scripts that system administrators may want to write to perform repetitive tasks.
Here are the most commonly used group management command-line tools:
▸ groupadd—This command creates and adds a new group.
▸ groupdel—This command removes an existing group.
▸ groupmod—This command creates a group name or GIDs but doesn’t add or delete members from a group.
▸ gpasswd—This command creates a group password. Every group can have a group password and an administrator. Use the -A argument to assign a user as group administrator.
▸ useradd -G—The -G argument adds a user to a group during the initial user creation. (More arguments are used to create a user.)
▸ usermod -G—This command allows you to add a user to a group as long as the user is not logged in at the time.
▸ grpck—This command checks the /etc/group file for typos.
Let’s say there is a DVD-RW device (/dev/scd0) on your computer that the system administrator wants a regular user named ryan to have permission to access. This is the process for granting ryan that access:
Add a new group with the
groupaddcommand:matthew@seymour:~$ sudo groupadd dvdrw
Change the group ownership of the device to the new group with the
chgrpcommand:matthew@seymour:~$ sudo chgrp dvdrw /dev/scd0
Add the approved user to the group with the
usermodcommand:matthew@seymour:~$ sudo usermod -G dvdrw ryan
Make user
ryanthe group administrator with thegpasswdcommand so that he can add new users to the group:matthew@seymour:~$ sudo gpasswd -A ryan
Now ryan has permission to use the DVD-RW drive, as would anyone else added to the group by either the super user or ryan because he is now also a group administrator and can add users to the group.
Managing Users
A user must be created, assigned a UID, provided a /home directory, provided an initial set of files for his or her /home directory, and assigned to groups in order to use the system resources securely and efficiently. The system administrator in some situations might want or need to restrict not only a user’s access to specific files and folders but also the amount of disk space an account may use.
User Management Tools
As with groups, Ubuntu provides several command-line tools for managing users, and it also provides graphical tools for doing so. As mentioned earlier, most experienced system administrators prefer the command-line tools because they are quick and easy to use, they are always available (even when there is no graphical user interface), and they can be included in scripts that system administrators may want to write to perform repetitive tasks. Here are the most common commands to manage users:
▸ useradd—This command adds a new user account to the system. Its options permit the system administrator to specify the user’s /home directory and initial group or to create the user with the default /home directory and group assignments (based on the new account’s username).
▸ useradd -D—This command sets the system defaults for creating the user’s /home directory, account expiration date, default group, and command shell. See the specific options in the useradd man page. Used without any arguments, the useradd command displays the defaults for the system. The default files for a user are in /etc/skel.
Note
The set of files initially used to populate a new user’s home directory is kept in /etc/skel. This is convenient for the system administrator because any special files, links, or directories that need to be universally applied can be placed in /etc/skel and will be duplicated automatically with appropriate permissions for each new user:
matthew@seymour:~$ ls -la /etc/skel total 32 drwxr-xr-x 2 root root 4096 2010-04-25 12:14 . drwxr-xr-x 154 root root 12288 2010-07-01 16:30 .. -rw-r--r-- 1 root root 220 2009-09-13 22:08 .bash_logout -rw-r--r-- 1 root root 3103 2010-04-18 19:15 .bashrc -rw-r--r-- 1 root root 179 2010-03-26 05:31 examples.desktop -rw-r--r-- 1 root root 675 2009-09-13 22:08 .profile
Each line provides the file permissions, the number of files housed under that file or directory name, the file owner, the file group, the file size, the creation date, and the filename.
As you can see, root owns every file here. The useradd command copies everything in /etc/skel to the new home directory and resets file ownership and permissions to the new user.
Certain user files might exist that the system administrator doesn’t want the user to change; the permissions for those files in /home/username can be reset so that the user can read them but can’t write to them.
▸ deluser—This command removes a user’s account (thereby eliminating that user’s home directory and all files it contains). There is an older version of this command, userdel, that previous versions of this book discussed. deluser is preferred because it provides finer control over what is deleted. Whereas userdel automatically removes both the user account and also all the user’s files, such as the associated /home directory, deluser deletes only the user account, unless you use a command-line option to tell it to do more. deluser includes options such as --remove-home, --remove-all-files, --backup, and more. See the man page for more information.
▸ passwd—This command updates the authentication tokens used by the password management system.
Tip
To lock a user out of his or her account, use the following command:
matthew@seymour:~$ sudo passwd -l username
This prepends an ! (exclamation point, also called a bang) to the user’s encrypted password; the command to reverse the process uses the -u option.
▸ usermod—This command changes several user attributes. The most commonly used arguments are -s to change the shell and -u to change the UID. No changes can be made while the user is logged in or running a process.
▸ chsh—This command changes the user’s default shell. For Ubuntu, the default shell is /bin/bash, known as the Bash, or Bourne Again Shell.
Adding New Users
The command-line approach to adding a user is quite simple and can be accomplished on a single line. In the following example, the system administrator uses the useradd command to add the new user sandra:
matthew@seymour:~$ sudo useradd sandra -p c00kieZ4ME -u 1042
The command adduser (a variant found on some UNIX systems) and useradd are similar and do the same thing. This example uses the -p option to set the password the user requested and the -u option to specify her UID. (If you create a user with the default settings, you do not need to use these options.) As you can see, all this can be accomplished on one line.
The system administrator can also use the graphical interface that Ubuntu provides to add the same account as shown in the preceding command but with fewer setting options available:
From the menu at the upper right of the desktop, select the Settings icon, which looks like a gear (see Figure 13.1). In the Settings application, from the bottom left select Users (see Figure 13.2).
FIGURE 13-1 Open the menu at the upper right to find the Settings icon.
FIGURE 13-2 Select Users.
Click Unlock at the upper right and enter your password to authorize making changes to user accounts.
Click Add User at the upper right, where Unlock was, to open the Add Account window.
Fill in the form with the new user’s name and desired username, select whether to set a password now or have the new user create a password the first time he or she logs in, and designate whether the new user is a standard user or an administrator, and click Add (see Figure 13.3).
FIGURE 13-3 Adding a new user is simple. The GUI provides a set of options for user management spread over several screens.
Note
A Linux username can be any alphanumeric combination that does not begin with a special character reserved for shell script use (mostly <space> and punctuation characters; see Chapter 14, “Automating Tasks and Shell Scripting,” for disallowed characters). A username is often the user’s first name plus the first initial of her last name or the first initial of the user’s first name and his entire last name. These are common practices on larger systems with many users because it makes life simpler for the system administrator, but neither convention is a rule or a requirement.
Monitoring User Activity on the System
Monitoring user activity is part of a system administrator’s duties and an essential task in tracking how system resources are being used. The w command tells the system administrator who is logged in, where he is logged in, and what he is doing. No one can hide from the super user. The w command can be followed by a specific user’s name to show only that user.
The ac command provides information about the total connect time of a user, measured in hours. It accesses the /var/log/wtmp file for the source of its information. The ac command is most useful in shell scripts to generate reports on operating system usage for management review. Note that to use the ac command, you must install the acct package from the Ubuntu repositories.
Tip
Interestingly, a phenomenon known as time warp can occur, where an entry in the wtmp files jumps back into the past, and ac shows unusual amounts of time accounted for users. Although this can be attributed to some innocuous factors having to do with the system clock, it is worthy of investigation by the system administrator because it can also be the result of a security breach.
The last command searches through the /var/log/wtmp file and lists all the users logged in and out since that file was first created. The user reboot exists so that you might know who has logged in since the last reboot. A companion to last is the command lastb, which shows all failed, or bad, logins. It is useful for determining whether a legitimate user is having trouble or a hacker is attempting access.
Note
The accounting system on your computer keeps track of user usage statistics and is kept in the current /var/log/wtmp file. That file is managed by the systemd processes. If you want to explore the depths of the accounting system, use the GNU info system: info accounting.
Managing Passwords
Passwords are an integral part of Linux security, and they are the most visible part to the user. In this section, you learn how to establish a minimal password policy for your system, where the passwords are stored, and how to manage passwords for your users.
System Password Policy
An effective password policy is a fundamental part of a good system administration plan. The policy should cover the following:
▸ Allowed and forbidden passwords
▸ Frequency of mandated password changes
▸ Retrieval or replacement of lost or forgotten passwords
▸ Password handling by users
The Password File
The password file is /etc/passwd, and it is the database file for all users on the system. The format of each line is as follows:
username:password:uid:gid:gecos:homedir:shell
The fields are self-explanatory except for the gecos field. This field is for miscellaneous information about the user, such as the user’s full name, office location, office and home phone numbers, and possibly a brief text note. For security and privacy reasons, this field is little used today, but the system administrator should be aware of its existence because the gecos field is used by traditional UNIX programs such as finger and mail. For that reason, it is commonly referred to as the finger information field. The data in this field is comma delimited; you can change the gecos field with the chfn (change finger) command.
Note that colons separate all fields in the /etc/passwd file. If no information is available for a field, that field is empty, but all the colons remain.
If an asterisk appears in the password field, that user is not permitted to log on. This feature exists so that a user can be easily disabled and (possibly) reinstated later without the need to create the user all over again. The traditional UNIX way of accomplishing this task is for the system administrator to manually edit this field. Ubuntu provides a more elegant method with the passwd -l command, mentioned earlier in this chapter.
Several services run as pseudo-users, usually with root permissions. These are the system, or logical, users mentioned previously. You would not want these accounts to be available for general login for security reasons, so they are assigned /sbin/nologin or /bin/false as their shell, which prohibits any logins from these accounts.
A list of /etc/passwd reveals the following (abridged for brevity):
matthew@seymour:~$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh messagebus:x:102:106::/var/run/dbus:/bin/false avahi:x:105:111:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false couchdb:x:106:113:CouchDB Administrator,,,:/var/lib/couchdb:/bin/bash haldaemon:x:107:114:Hardware abstraction layer,,,:/var/run/hald:/bin/false kernoops:x:109:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false gdm:x:112:119:Gnome Display Manager:/var/lib/gdm:/bin/false matthew:x:1000:1000:Matthew Helmke,,,,:/home/matthew:/bin/bash sshd:x:114:65534::/var/run/sshd:/usr/sbin/nologin ntp:x:115:122::/home/ntp:/bin/false pulse:x:111:117:PulseAudio daemon,,,:/var/run/pulse:/bin/false
Note that none of the password fields show a password but rather contain an X. This is because they are shadow passwords, a useful security enhancement to Linux.
Shadow Passwords
Keeping passwords in /etc/passwd is considered a security risk because anyone with read access could run a cracking program on the file and obtain the passwords with little trouble. To avoid this risk, shadow passwords are used so that only an X appears in the password field of /etc/passwd; the real passwords are kept in /etc/shadow, a file that can be read only by the system administrator (and PAM, the Pluggable Authentication Modules authentication manager; see the “PAM Explained” sidebar, later in this chapter, for an explanation of PAM).
Special versions of the traditional password and login programs must be used to enable shadow passwords. Shadow passwords are automatically enabled during installation of Ubuntu. Examine the following abbreviated listing of the shadow companion to /etc/passwd, the /etc/shadow file:
matthew@seymour:~$ sudo cat /etc/shadow root:!:14547:0:99999:7::: daemon:*:14544:0:99999:7::: bin:*:14544:0:99999:7::: sys:*:14544:0:99999:7::: games:*:14544:0:99999:7::: man:*:14544:0:99999:7::: mail:*:14544:0:99999:7::: www-data:*:14544:0:99999:7::: irc:*:14544:0:99999:7::: nobody:*:14544:0:99999:7::: libuuid:!:14544:0:99999:7::: syslog:*:14544:0:99999:7::: messagebus:*:14544:0:99999:7::: kernoops:*:14544:0:99999:7::: gdm:*:14544:0:99999:7::: matthew:$6$wtML.mV4$.I5WeTp9tgGkIjJM4uLR5p6TVUqPrSvJ0N2W/t//0jVBrWQrOySEEDvXsA/sKSEl QsfmNmfPJYxVrjZ21/Ir70:14564:0:99999:7::: sshd:*:14547:0:99999:7::: ntp:*:14548:0:99999:7::: usbmux:*:14724:0:99999:7::: pulse:*:14725:0:99999:7:::
The fields are separated by colons and are, in order:
▸ The user’s login name.
▸ The encrypted password for the user.
▸ The day on which the last password change occurred, measured in the number of days since January 1, 1970. This date is known in UNIX circles as the epoch. Just so you know, the billionth second since the epoch occurred was in September 2001; that was the UNIX version of Y2K—and as with the real Y2K, nothing much happened.
▸ The number of days before the password can be changed (which prevents changing a password and then changing it back to the old password right away—a dangerous security practice).
▸ The number of days after which the password must be changed. This can be set to force the change of a newly issued password known to the system administrator.
▸ The number of days before the password expiration that the user is warned it will expire.
▸ The number of days after the password expires that the account is disabled (for security).
▸ Similar to the password change date, although this is the number of days since January 1, 1970, that the account has been disabled.
▸ A “reserved” field that is not currently allocated for any use.
Note that password expiration dates and warnings are disabled by default in Ubuntu. These features are not often used on home systems and usually are not even used for small offices. It is the system administrator’s responsibility to establish and enforce password expiration policies if they are to exist.
The permissions on the /etc/shadow file should be set so that it is not writable or readable by regular users: The permissions should be 600.
PAM Explained
Pluggable Authentication Modules (PAM) is a system of libraries that handle the tasks of authentication on a computer. It uses four management groups: account management, authentication management, password management, and session management. This allows the system administrator to choose how individual applications will authenticate users. Ubuntu has preinstalled and preconfigured all the necessary PAM files for you.
The configuration files in Ubuntu are in /etc/pam.d. Each of these files is named for the service it controls, using the following format:
type control module-path module-arguments
The type field is the management group that the rule corresponds to. The control field tells PAM what to do if authentication fails. The final two items deal with the PAM module used and any arguments it needs. Programs that use PAM typically come packaged with appropriate entries for the /etc/pam.d directory. To achieve greater security, the system administrator can modify the default entries. Misconfiguration can have unpredictable results, so back up the configuration files before you modify them. The defaults provided by Ubuntu are adequate for home and small office users.
An example of a PAM configuration file with the formatted entries as described previously is shown next. Here are the contents of /etc/pam.d/gdm:
#%PAM-1.0 auth requisite pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale auth sufficient pam_succeed_if.so user ingroup nopasswdlogin @include common-auth auth optional pam_gnome_keyring.so @include common-account session [success=ok ignore=ignore module_unknown=ignore default=bad] [ccc]pam_selinux.so open session required pam_limits.so @include common-session session [success=ok ignore=ignore module_unknown=ignore default=bad] [ccc]pam_selinux.so close session optional pam_gnome_keyring.so auto_start @include common-password
Amusingly, even the PAM documents state that you do not really need (or want) to know a lot about PAM to use it effectively.
You will likely need only the PAM system administrator’s guide. You can find it at www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html.
Managing Password Security for Users
Selecting appropriate user passwords is always an exercise in trade-offs. A password such as password (do not laugh, it has been used often in the real world and with devastating consequences) is just too easy to guess by an intruder. So are simple words or number combinations (the numbers from a street address or date of birth, for example). You would be surprised how many people use easily guessed passwords such as 123456, iloveyou, Qwerty, and abc123.
In contrast, a password such as 2a56u'"F($84u&#^Hiu44Ik%$([#EJD is sure to present great difficulty to an intruder (or an auditor). However, that password is so difficult to remember that it would be likely that the password owner would write that password down on a sticky note attached to his monitor.
The system administrator has control, with settings in the /etc/shadow file, over how often the password must be changed. The settings can be changed by the super user using a text editor or the chage command. (See the shadow and chage man pages for details.)
Changing Passwords in a Batch
On a large system, there might be times when a large number of users and their passwords need some attention. The super user can change passwords in a batch by using the chpasswd command, which accepts input as a name/password pair per line in the following form:
matthew@seymour:~$ sudo chpasswd username:password
Passwords can be changed en masse by redirecting a list of name and password pairs to the command. An appropriate shell script can be constructed with the information gleaned from Chapters 11 and 12, “Command-Line Master Class, Part 1” and “Command-Line Master Class, Part 2,” combined with information on writing scripts from Chapter 14.
However, Ubuntu also provides the newusers command to add users in a batch from a text file. This command also allows a user to be added to a group, and a new directory can be added for the user, too.
Granting System Administrator Privileges to Regular Users
On occasion, regular users might need to run a command as if they were the root user. They usually do not need these powers, but a user might require such abilities on special occasions—for example, to temporarily access certain devices or run a command for testing purposes.
There are two ways to run commands with root privileges. The first way is useful if you are the owner of both the super user account (an enabled root account) and a regular user; the second way is useful if you are a regular user but are not privileged to access all super user functions. (This might happen on a large, multiuser network with senior and junior administrators as well as regular users.) Let’s look at each.
Temporarily Changing User Identity with the su Command
This first scenario requires the existence of a root account, which is not enabled by default on Ubuntu systems and is not generally recommended in the Ubuntu community. However, there are times when it makes sense. Discussing that is beyond the scope of this chapter, but for the sake of argument, for the scenario and details in this section, assume that you are operating in one of those special cases and that a root account has been enabled.
What if you have access to an enabled root account as a super user but are logged on as a regular user because you are performing nonadministrative tasks, and you find that you need to do something that only the super user can do? The su command is available for this purpose.
Note
A popular misconception is that the su command is short for super user; it really just means substitute user. An important but often overlooked distinction is that between su and su -. In the former instance, you become that user but keep your own environmental variables (such as paths). In the latter, you inherit the environment of that user. This is most noticeable when you use su to become the super user, root. Without appending the -, you do not inherit the path variable that includes /bin or /sbin, so you must always enter the full path to those commands when you just su to root.
Don’t forget that on a standard Ubuntu system, the first created user is classed as root, whereas the true root account is disabled. To enable the root account, you enter the command sudo passwd at the command line and enter your password and a new root password. After this has been completed, you can su to root. We suggest you read the information at https://help.ubuntu.com/community/RootSudo before doing so to ensure that you understand the reason the root account is not enabled by default.
Because almost all Linux file system security revolves around file permissions, it can be useful to occasionally become a different user with permission to access files belonging to other users or groups or to access special files (such as the communications port /dev/ttyS0 when using a modem or the sound device /dev/audio when playing a game). You can use the su command to temporarily switch to another user identity and then switch back.
The su command spawns a new shell, changing both the UID and GID of the existing user and automatically changing the environmental variables associated with that user, known as inheriting the environment. For more information about environment variables, see Chapter 6, “Productivity Applications.”
The syntax for the su command is as follows:
matthew@seymour:~$ su option username arguments
The man page for su gives more details, but some highlights of the su command are as follows:
-c, --command
pass a single COMMAND to the shell with –c
-m, --preserve-environment
do not reset environment variables
-l a full login simulation for the substituted user,
the same as specifying the dash alone
You can invoke the su command in different ways that yield diverse results. By using su alone, you can become root, but you keep your regular user environment. This can be verified by using the printenv command before and after the change. Note that the working directory (you can execute pwd at the command line to print the current working directory) has not changed. By executing the following, you become root and inherit root’s environment:
matthew@seymour:~$ su –
By executing the following, you become that user and inherit the super user’s environment—a pretty handy tool. (Remember: Inheriting the environment comes from using the dash in the command; omit that, and you keep your “old” environment.) To become another user, specify a different user’s name on the command line:
matthew@seymour:~$ su - other_user
When leaving an identity to return to your usual user identity, use the exit command. For example, while logged on as a regular user, use the following:
matthew@seymour:~$ su – root
The system prompts for a password:
Password:
When the password is entered correctly, the root user’s prompt appears:
root~#
To return to the regular user’s identity, just type the following:
root~# exit
This takes you to the regular user’s prompt:
matthew@seymour:~$
If you need to allow other users access to certain commands with root privileges, you must give them the password for the root account (often referred to as the root password) so that they can use su; that definitely is not a secure solution. The next section describes a more flexible and secure method of allowing normal users to perform selected root tasks and the preferred method for sharing and using super user privileges in Ubuntu.
Note
The su command is often seen as bad because what it is supposed to do is a bit ambiguous. On one hand, it is supposed to open a new session and change a number of execution parameters while also inheriting parameters from the session in which it was issued. It does give you a new execution shell, but that is not really the same thing as a full login. systemd has added a new command, machinectl shell, that is intended to do this “properly,” according to its creators. Because systemd is covered in Chapter 15, “The Boot Process,” this new command is also covered there.
Granting Root Privileges on Occasion: The sudo Command
Delegating some of the authority that root wields on a system is often necessary. For a large system, this makes sense because no single individual will always be available to perform super user functions. The problem is that UNIX permissions come with all-or-nothing authority. Enter sudo, an application that permits the assignment of one, several, or all the root-only system commands.
Note
As mentioned earlier, the sudo command is pervasive in Ubuntu because it is used by default. If you want to get to a root shell, thereby removing the need to type sudo for every command, just enter sudo -i to get the root prompt. To return to a normal user prompt, enter exit, and press Enter. Again, this is a bit dangerous because if you are not paying attention and forget to exit root, you could cause severe damage to the system. It is usually better to choose one method or the other and use it consistently, and the Ubuntu community consistently uses and recommends using sudo for each command, even if it gets tedious, because it is a good reminder to think about what you are doing.
After it is configured, using sudo is simple. An authorized user merely precedes a super user authority–needed command with sudo, like this:
matthew@seymour:~$ sudo command
When the command is entered, sudo checks the /etc/sudoers file to see whether the user is authorized to wield super user privileges; if so, sudo use is authorized for a specific length of time. The user is then prompted for her password (to preserve accountability and provide some measure of security), and then the command is run as if root had issued it. During the time allotted, which is 15 minutes by default in Ubuntu, sudo can be used again once or multiple times without a password. If an unauthorized user attempts to execute a sudo command, a record of the unauthorized attempt is kept in the system log, and a mail message is sent to the super user.
Three man pages are associated with sudo: sudo, sudoers, and visudo. The first covers the command itself, the second the format of the /etc/sudoers file, and the third the use of the special editor for /etc/sudoers. You should use the special editing command because it checks the file for parse errors and locks the file to prevent others from editing it at the same time. The visudo command uses the vi editor, so you might need a quick review of the vi editing commands found in Chapter 12 in the section “Working with vi.” You begin the editing by executing the visudo command with this:
matthew@seymour:~$ sudo visudo
The default /etc/sudoers file looks like this:
# /etc/sudoers
#
# This file MUST be edited with the 'sudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:
/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(All:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
The basic format of a sudoers line in the file is as follows:
user host_computer=command
The user can be an individual user or a group. (A % in front identifies a name as a group.) The host_computer is normally ALL for all hosts on the network and localhost for the local machine, but the host computer can be referenced as a subnet or any specific host. The command in the sudoers line can be ALL, a list of specific commands, or a restriction on specific commands (formed by prepending a ! to the command). A number of options are available for use with the sudoers line, and aliases can be used to simplify the assignment of privileges. Again, the sudoers man page gives the details, but let’s look at a few examples.
Suppose that you want to give user john permission across the network to be able to add users with the graphical interface. You would add the following line:
john ALL=/users-admin
Or perhaps you would grant permission only on the user’s local computer:
john 192.168.1.87=/usr/bin/users-admin
If you want to give the editor group system-wide permission with no password required to delete files, you use the following:
%editors ALL=NOPASSWD: /bin/rm
If you want to give every user permission with no password required to mount the CD drive on the localhost, you do so as follows:
ALL localhost=NOPASSWD:/sbin/mount /dev/scd0 /mnt/cdrom /sbin/umount /mnt/cdrom
Using wildcards in the construction of the sudoers file is also possible. Aliases can be used, as well, to make it easier to define users and groups. The man page for sudoers contains some examples, and www.komar.org/pres/sudo/toc.html provides illustrative notes and comments about sudo use at a large company. The sudo home page at www.sudo.ws is also a useful resource for additional explanations and examples.
The following command presents users with a list of the commands they are entitled to use:
matthew@seymour:~$ sudo –l
Disk Quotas
On large systems with many users, you often need to control the amount of disk space a user can use. Disk quotas are designed specifically for this purpose. Quotas, managed per partition, can be set for both individual users and groups; quotas for groups need not be as large as the aggregate quotas for the individuals in the groups.
When a file is created, both a user and a group own it. Ownership of files is always part of the metadata about the files. This makes quotas based on both users and groups easy to manage.
Note
Disk quota management is not really useful or needed on a home system and rarely, if ever, on a small office system. It is unlikely that you will see or implement this in either circumstance.
To manage disk quotas, you must have the quota and quotatool packages installed on your system. Quota management with Ubuntu is not enabled by default and has traditionally been enabled and configured manually by system administrators. System administrators use the family of quota commands, such as quotacheck to initialize the quota database files, edquota to set and edit user quotas, setquota to configure disk quotas, and quotaon or quotaoff to control the service. (Other utilities include warnquota for automatically sending mail to users over their disk space usage limit.)
Implementing Quotas
Quotas are not enabled by default, even if the quota software package is installed on your Ubuntu system. When quotas are installed and enabled, you can see which partitions have either user quotas, group quotas, or both by looking at the fourth field in the /etc/fstab file. For example, one line in /etc/fstab shows that quotas are enabled for the /home partition:
/dev/hda5 /home ext3 defaults,usrquota,grpquota 1 1
The root of the partition with quotas enabled will have the file quota.user or the file quota.group in it (or both files, if both types of quotas are enabled), and the files will contain the actual quotas. The permissions of these files should be 600 so that users cannot read or write to them. (Otherwise, users would change them to allow ample space for their music files and Internet art collections.) To initialize disk quotas, the partitions must be remounted. This is easily accomplished with the following:
matthew@seymour:~$ sudo mount -o ro,remount partition_to_be_remounted mount_point
The underlying console tools (all of which have man pages) are as follows:
▸ quotaon and quotaoff—Toggle quotas on a partition
▸ repquota—Provides a summary status report on users and groups
▸ quotacheck—Updates the status of quotas (compares new and old tables of disk usage); run after fsck
▸ edquota—Enables basic quota management
Manually Configuring Quotas
Manual configuration of quotas involves changing entries in your system’s file system table, /etc/fstab, to add the usrquota mount option to the desired portion of your file system. As an example, in a simple file system, you can enable quota management like this:
LABEL=/ / ext3 defaults,usrquota 1 1
You can also enable group-level quotas by using the grpquota option. Then, as the root operator in the example of creating user quotas, you must create a file named quota.user in the designated portion of the file system, like so:
matthew@seymour:~$ sudo touch /quota.user
You should then turn on the use of quotas by using the quotaon command:
matthew@seymour:~$ sudo quotaon –av
You can then edit user quotas with the edquota command to set hard and soft limits on file system use. The default system editor (vi unless you change your EDITOR environment variable) is launched when editing a user’s quota.
Users can find out what their quotas are with the following:
matthew@seymour:~$ quota –v
Note
Ubuntu does not support any graphical tools that enable you to configure disk quotas. A Quota mini-HOWTO is maintained at www.tldp.org/HOWTO/Quota.html.
Related Ubuntu Commands
You use these commands to manage user accounts in Ubuntu:
▸ ac—Provides user account statistics
▸ change—Sets or modifies user password expiration policies
▸ chfn—Creates or modifies user finger information in /etc/passwd
▸ chgrp—Modifies group memberships
▸ chmod—Changes file permissions
▸ chown—Changes file ownerships
▸ chpasswd—Modifies user passwords in batches
▸ chsh—Modifies a user’s shell
▸ groups—Displays existing group memberships
▸ logname—Displays a user’s login name
▸ newusers—Batches user management command
▸ passwd—Creates or modifies user passwords
▸ su—Executes a shell or command as another user
▸ sudo—Manages selected user execution permissions
▸ useradd—Creates, modifies, or manages users
▸ usermod—Edits a user’s login profile
References
▸ https://tldp.org/HOWTO/User-Authentication-HOWTO/—A HOWTO that describes how user and group information is stored and used for authentication
▸ https://tldp.org/HOWTO/Shadow-Password-HOWTO.html—A HOWTO that delves into the murky depths of shadow passwords and even discusses why you might not want to use them.
▸ https://tldp.org/HOWTO/Security-HOWTO/—A must-read HOWTO that provides a good overview of security issues, including creating accounts, file permissions, and password security.
▸ https://tldp.org/LDP/sag/html/index.html—A general guide, the Linux System Administrator’s Security Guide has interesting sections on limiting and monitoring users.
▸ www.kernel.org/pub/linux/libs/pam—The Pluggable Authentication Modules suite contains complex and highly useful applications that provide additional security and logging for passwords. PAM is installed by default in Ubuntu. Understanding the intricacies of PAM isn’t necessary to use it effectively.