Users

Linux is a multiuser operating system, meaning that it provides features to help multiple individuals use the computer. Collectively, these features constitute accounts.

Related to accounts are groups, which are collections of accounts that can be given special permissions on the computer.

One account, known as root, has special privileges on the computer. You use this account to perform most system administration tasks, so you should understand this account before you tackle the administrative tasks. These important topics are at the foundation of system security.

/etc/passwd

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:

vader:x:1003:100:Darth Vader:/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, as are dollar signs ($) at the end.

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; it has a password in most distributions. 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.

UID In reality, the username is just a label that the computer displays to humans. The computer uses 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. Some distributions number user accounts starting at 500 rather than 1,000.

GID Accounts are tied to one or more groups. Groups 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 users access to their files, while preventing others from accessing them. Each account is tied directly to a primary group via a group ID (GID) number. Accounts can be tied to other groups by inclusion in the group's definition.

Comment Field The comment field normally holds the user's full name, 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. 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.

/etc/shadow

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.

Passwords are stored using a salted hash, a one-way mathematical process with additional random input (salt), that produces what looks like nonsense to humans. When a user types a password, it's salted and hashed, andif the salted hashes match, access is granted. A typical /etc/shadow entry looks like this:

vader:$1$E/moFkeT5UnTQ3KqZUoA4Fl2tPUoIc:16860: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 (16860 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 for a gap between the expiration of an account and its complete deactivation. 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, a value of -1 or 99999 typically indicates that the relevant feature has been disabled. The /etc/shadow values are generally best left to modification through commands such as usermod 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-root 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.

The terms encrypted and hashed are often confused when used with computer objects. You can decrypt an encrypted object, but you cannot "dehash" a hashed object. Passwords on Linux are salted and hashed, though often you'll see the term encrypted mistakenly used instead in Linux documentation.

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.

Examples of user files stored outside the user's home directory include email in /var/spool/mail and temporary files in /tmp.

Adding Users

You use the useradd utility to create an account from the command line. To use this utility, you type its name and the username that you want to associate with a new account.

Note: It is possible to add a password with the useradd command's -p option. However, for security reasons, this is not reccommended. It is better to user the passwd command.

A complete useradd command, including setting a few options, looks like this:

useradd -m -c "Darth Vader" -u 1012 vader

This example creates an account with a username vader, a home directory, a comment field containing the user's full name, and a UID of 1012.

You might want to specify a UID to keep these values synchronized across computers that share files with the Network File System (NFS), which identifies file ownership via UIDs.

When you create an account with useradd, it will be in a locked state - the user will not be able to log in. To unlock it, you must use the passwd command.

If you use --create-home or -m, or if this option is used by default, the program creates a home directory and copies files from /etc/skel to that location. Creating an account will also usually create a mail spool file in which the user's incoming email will be stored. (This file may go unused on many desktop systems, but it can be important if you run mail server software on the computer.) Thus you can see that useradd makes quite a few modifications to your computer's files and directories in creating the account.

Deleting Users

Deleting accounts can sometimes be as important as adding or modifying them. Unused accounts can be abused, either by their former owners or by others who might be able to break into an account if it has a weak password. Thus you should routinely delete unused accounts. Before you do so, though, you should understand what happens when you delete an account and decide precisely how to do it, lest you create problems by deleting an account in an inappropriate way.

Avoiding Account-Deletion Pitfalls

Deleting an account may sound simple enough, but a mistake can cause problems, either immediately or in the future. In addition to obvious issues such as accidentally deleting the wrong account, you should consider two factors:

User File Preservation

Users’ files might be extremely valuable, either to the users themselves or to the organization that owns the computer. Thus you should check your company’s file retention policies when considering whether to delete the user’s home directory or do something else with it, such as move it into another user’s home directory and change permissions on the files it contains. The same is true of the user’s mail queue (normally stored in /var/spool/mail/username, where username is the username).

Consider archiving a deleted account’s home directory to a long-term backup medium. This will enable you to recover the files should they become valuable in the future.

UID and GID Reuse

When an account is deleted, the account’s UID and GID become available for reuse. In many cases, these numbers will not be reused, since Linux assigns these values based on the highest current value. Thus if you delete any but the highest-numbered current user, the user’s old UID and GID numbers won’t be reused unless intervening accounts are also deleted. Nonetheless, if a UID is reused, any files previously owned by the old user will suddenly appear to be owned by the new user. This might not cause any problems, but it might cause confusion about who created the files. In some cases, it could even cause suspicion of wrongdoing by the new user (if the old files contain information the new user shouldn’t have, or if they reside in directories to which the new user shouldn’t have access).

If you want to avoid any chance of confusion or misbehavior claims falling on new users due to UID or GID reuse, you can use the find command to locate all files with particular UID or GID values, using the -uid and -gid options, as in:

# find / -uid 1004

You can issue this command as a non-root user, but it will return errors and it may miss some files. Thus it’s best to do this with superuser privileges.

This example finds all files on the computer with a UID of 1004. (Searching on a GID works the same way, but using the -gid option.) You can then reassign ownership of these files by using the chown command or delete them. Ordinarily, you’d issue this command only after deleting or reassigning ownership of the user’s home directory, since that directory will probably contain far too many matching files.

Deleting Accounts From the Shell

The userdel command deletes accounts from a text-mode shell. In its simplest form, you pass it a username and nothing more:

userdel vader

Notice that in the userdel examples, the sudo command is used to obtain superuser privileges, which are required to complete this command successfully. If you were logged into the root account, sudo would not be needed.

The program doesn’t prompt you for confirmation; it just deletes the account. It does not, however, delete the user’s home directory by default. To have it do so, pass it the --remove (-r) option.

If the user is currently logged in, userdel notifies you of that fact and does nothing. You can pass it the --force (-f) option to delete the account even though it’s in use. To both force account deletion and remove the user’s files, you can pass both options:

userdel -rf vader

userdel: user vader is currently logged in

The program still complains about the user being logged in, but it deletes the account and files just the same.

Groups

In many respects, groups are comparable to accounts. They’re defined in similar files and managed with similar utilities. Groups are also tied to accounts, in that accounts include group definitions. Until now, it has been assumed that you’ll be using standard groups or the groups that are defined as part of account creation. Sometimes, though, you need to create, delete, or modify groups for specific purposes, such as if you use a project group strategy.

Adding Groups

You can create groups from the shell by using the groupadd command, which works much like useradd for users but takes a smaller set of options. Consult the program’s man pages for information on more-obscure options.

Using the groupadd command, including setting an option, looks like this:

# groupadd -g 1001 groupname

This example creates a group with a GID of 1001 and a group name of groupname.

Once the group is added, new members can be added to the group. This requires the use of the usermod command, as follows:

usermod -aG groupname vader

The -aG options were used together to add the account, vader, to the new groupname group. If the -a option was not used, the vader account would be removed from its current group memberships and belong only to the groupname group. A good habit is to check if the modification was successful by using the groups command. The groups command shows all of the group memberships for the specified user account.

To modify the group itself, you can use the groupmod command. The --gid (-g) and --non-unique (-o) options can be used with this command, as well as --new-name name (-n name), which changes the group’s name.

Deleting Groups

Deleting groups from the shell entails use of the groupdel command, which takes a group name as a single option, as in groupdel groupname to delete the groupname group.

How To's

To see the groups that your Linux ID belongs to, use the command:

groups

[root@hdcentos infauser]# groups
root

To see the groups that a particular Linux ID belongs to, use the command:

groups userid

[root@hdcentos infauser]# groups infauser
infauser : infauser

To see a list of all groups:

cat /etc/group

...
stapusr:x:156:
stapsys:x:157:
stapdev:x:158:
osboxes:x:1000:osboxes
reo:x:1001:
hduser:x:1002:
hadoop:x:982:yarn,mapred,hdfs
yarn:x:981:
mapred:x:980:
hdfs:x:979:
Rodney:x:1003:
infauser:x:1004:

To see a list of all users that belong to a group, like the 'root' group:

getent group root

root:x:0:

To change a password on behalf of a user, first sign on or "su" to the "root" account. Then type:

passwd userID

The system will prompt you to enter a password. Passwords do not echo to the screen when you enter them.

The wheel Group

Linux distributions invariably provide several groups by default. One of these, wheel (on some distributions), is particularly important for system administration. Members of the wheel group are granted certain special administrative privileges, such as the right to use the sudo command. The group name comes from the slang term big wheel, which refers to an important person.

Not all distributions provide this particular group. You can type grep wheel /etc/group to determine if the wheel group exists on your distribution.

Some distributions enable you to add your primary user account to the wheel group when you install the OS. Be aware that this phrasing is not used often; instead, the installer asks if you want to add the account to the “administrators group” or some similar term.