In this chapter you will learn

Even if you are the only human with access rights to a particular Linux host, you are still dealing with at least two user accounts, root and your own user account. There are also a number of user accounts that belong to various services and programs on a Linux host.

Much of this chapter is about creating and managing user accounts. We will spend a significant amount of time on the files used to manage user accounts, passwords, and security.

Your Linux computer has many accounts even if no other human actually uses your computer on a regular basis. Most of those accounts are used by Linux when it performs particular functions.

One of the special accounts is that of root. The root account is present on all Linux computers, and it allows the person logged in as root to read, change, and delete any file on the computer regardless of who owns the files. The root account is restricted by file permissions, but root can change the permissions of any file on the computer. The root account can do anything and everything on a Linux computer even changing the password of any user or locking out users. To protect the integrity of the system, the only person who should have the root password to a Linux computer is the system administrator.

By virtue of logging in using your account ID and password, you are granted access to read and write files that are located in your home directory because you are the owner of those files. You can create new files and directories in your home directory and modify them as you see fit.

Your account does not provide you enough rights to access other user’s home directories let alone view or modify the files located there. Your account does not have sufficient rights to alter any important system files, although you may be able to see some of them and view the contents of some.

There is a common practice to create account names using the first letter of your first name and your last name. Thus, the person Jo User would have an account name of juser. Notice that it is also common practice for the account name to be all lowercase. Case is important in Linux, so the account name JUser is not the same as juser.

User accounts and groups are the first line of security on your Linux computer. Knowledge of user accounts and file permissions will make it much less frustrating for you as you do your work.

The root account is always UID 0 and the root group is always GID 0.

Historically, all system-level users were assigned a UID and GID between 1 and 99. Convention defined the specific user and group IDs for various programs and services. For a time, Red Hat, and therefore Fedora, recommended starting human user and group IDs at UID 500 and GID 500. That was inconsistent with other Linux distributions and caused some issues.

Today, because of a proliferation of services and system-level account needs, all of the newer standard Linux system- and application-level users are located in the UID range between 100 and 999 which is now reserved for this purpose.¹ All application-level users – those required by installed services and applications – should be added in the UID range between 101 and 999. All regular (human) users should be added starting at UID 1000 and above.

The RHEL 7 System Administrator's Guide goes further and recommends starting human user IDs at 5000² to allow for future expansion of the system IDs. However, the current RHEL and Fedora implementations still begin at UID/GID 1000 for human users. The guide does explain how to make this change so that new users are automatically assigned IDs in the recommended range.

Group ID assignments should follow the same practices as UIDs to help ensure consistency and to make troubleshooting easier.

There are some interesting historical anomalies within this structure. For example, GID 100 is reserved for the “Users” group. In some environments it is common for all regular users to be added to this group, but this is not recommended as it constitutes a security risk that would allow users to have access to one another’s files.

For regular users the UID and GID should be identical, that is, a user with UID 1001 should have a GID of 1001 as well. Since each user belongs to its own group, security is enhanced because files are not automatically shared between users. By default, users should not all belong to a single common primary group such as the Users group (GID 100).

Making files available to other users should be accomplished by using secondary group memberships to which the sharing users all belong and a directory where shared files can be stored and which has group ownership by the common group. Group membership should be limited to those who have a specific need to share related files. This allows for more granular management of shared files. We experimented with how to do this in Chapter 18 of Volume 1.

When adding group IDs for things like shared directories and files, I like to choose numbers starting at 5000 and above, as we did in Chapter 18. This allows space for 4000 users with identical UID and GID numbers. That should be more than enough for most Linux installations. Your needs may differ so you should adapt as necessary.

Figure 16-1 shows the conventional and currently common usage assignments for UID and GID ranges. The range from 0 to 999 and the ID 65534 should be considered as completely unusable for use or assignment by the SysAdmin. The range between 1000 and 65533 can be considered flexible and can be used according to local requirements.

User and group ID data are stored in the files /etc/passwd, /etc/shadow, and /etc/group.

It is advisable as a good security precaution to change your password about once a month. This prevents other people from using your password for very long even if they happen to discover it. Once you have changed it, they can no longer use your previous password to access the system. You never know when or how someone might obtain or guess your password, so even if you do not think it has been compromised, you should change your password regularly. Of course a password should be changed immediately if you suspect that it has been compromised.

Passwords should be protected and never written down. If a password is stolen, it can be used to access your computer and the network if your computer is so connected and thus compromise your data.

Linux requires passwords to be a specified minimum length. The default is five characters but that can be changed. I recommend that you use a longer password to increase the difficulty of someone guessing your password. Passwords should never be dates, initials, acronyms, words, or easy-to-remember sequences such as “ASDFG” from the left of the middle row of the keyboard. Passwords should be composed of upper- and lowercase alphabetic characters as well as numbers and special characters.

My personal calculations show that an automated attack of 500 access attempts per second on a host with a five-character password can be cracked in anywhere from 6 hours to 21 days depending upon whether the password contains only lowercase alpha or upper- and lowercase as well as numbers. The time to crack a really good randomly generated password that includes special characters (#$%^, etc.) rises to 152 days. This should be set to a minimum of eight to ensure a reasonable amount of security. The time to crack an eight-character password rises to 13 years to over 325,000 years, once again depending upon using upper- and lowercase, numbers, and special characters.

Crackers – bad hackers, people who want to get into your computer – have dictionaries of words, common acronyms, and key sequences that they can try to attempt to crack into your system. They also try easy-to-guess sequences that are available to anyone with a little persistence such as birthdays; anniversaries; the names of spouses, children, pets, or significant others; Social Security numbers; and other possible passwords of this type. The point is that when you change your password, you should choose one that is not based on a dictionary word or one that will be easy to guess or deduce from your personal information. Passwords based on any of these non-random sources will likely be cracked in seconds.

There is a significant downside of changing passwords frequently and setting strict policies that require them to be excessively long and not easily memorized. Such policies will almost certainly result in users who write their passwords on post-it notes and stick them on the display or under the keyboard. There is a fine line between workable security and self-defeating security.

Managing user accounts is a very common task for system administrators in many environments. This can include adding new accounts, deleting accounts that are no longer needed, and modifying existing accounts.

There are at least three methods that can be used to create, delete, and modify user accounts. Most desktop environments have some form of GUI tool. There are command-line tools useradd and adduser; the latter is simply a symlink to useradd but is retained for backward compatibility as well as commands to delete and to modify user accounts. And there is also the very retro method of editing the required files by hand.

In the next few experiments, we will manage user accounts using the command line and by manually editing the various files. I liked editing these files by hand when I was first learning because it provided me with knowledge of what the commands actually do as well as all of the files required and their structures.

Sometimes it may become necessary to force a user account to log off. This may be required because a user has left for the day and the system needs to be updated with no users logged in, the user has left the organization, or there may be one or more runaway processes.

Whatever the reason, there is no “logout other user” command, but there is a simple way to deal with this need to force the termination of all processes belonging to a user. This is, in fact, even more effective than simply forcing a logout.

You might think that with huge amounts of disk space, high CPU counts and speeds, gigabytes of RAM, and terabytes of disk space that modern Linux hosts do not have limited resources. That is not true, and I have seen huge systems overburdened by programs in test or even fully released programs that were poorly written. More frequently, I have caused myself problems where a shell script I have written sucks up most or all of some critical resource. You saw how easy that was when we did it intentionally earlier in this course. It seems to be even easier when it is unintentional.

So imagine for a moment that you are the system administrator for a Linux box that has a large number of users. And that one of those user accounts is running resource hogs – large jobs that suck up CPU time and memory which slows the tasks being run by other users to a crawl. They all come complaining to you. What do you do?

These issues can be corrected immediately by killing all of the processes – or at least the offending ones – belonging to the user owning them.

It is even better to prevent these problems by setting limits on the amount of system resources that a user, users, or groups can consume. The /etc/security/limits.conf file can be used to set limits for system resources to levels that will affect other users not at all or at least only marginally. A related option is to add a local config file to the /etc/security/limits.d directory. This prevents making changes to the main configuration file such as might occur during updates or complete reinstallations.

There are soft and hard limits that can be set. A soft limit sends a message when it is met or exceeded, while a hard limit prevents completion of the command that caused it. Both hard and soft limits can be set on a resource so that the user first receives a message and then is prevented from continuing. The limits set in this file are monitored and enforced by the pluggable authentication module (PAM) system which we will encounter again in Chapter 17 of this volume.

Limits can be applied to individual users, to groups such as dev or accounting, and to lists of users or groups, as well as to all users or groups.

Resource limitations must be considered with care, especially when applying them to groups and multiple users. This is an excellent way to ensure that the desires of the few do not outweigh the needs to the many.

This chapter has taken us through the processes of creation, modification, and deletion of user accounts. We have also explored the various configuration files that support user accounts and their creation. We have created user accounts using the command-line tools and have also used Vim to add a new user by direct editing of the passwd, group, and shadow files.

We have also looked at user account security in general and password security in particular. This included exploring configuration tools that can force users to change their passwords on a regular basis as well as to enforce some aspects of password security policy.

We have also explored multiple methods to deal with resource allocation problems and how to kick users off the system who are abusing resources.

Perform these exercises to complete this chapter: