6.3. Red Hat Linux-Specific Information
The following sections describe the various features specific to Red Hat Linux that relate to the administration of user accounts and associated resources.
6.3.1. User Accounts, Groups, and Permissions
Under Red Hat Linux, a user can log into the system and use any applications or files they are permitted to access after a normal user account is created. Red Hat Linux determines whether or not a user or group can access these resources based on the permissions assigned to them.
There are three different permissions for files, directories, and applications. These permissions are used to control the kinds of access allowed. Different one-character symbols are used to describe each permission in a directory listing. The following symbols are used:
r — Indicates that a given category of user can read a file.
w — Indicates that a given category of user can write to a file.
x — Indicates that a given category of user can execute the contents of a file.
A fourth symbol (-) indicates that no access is permitted.
Each of the three permissions are assigned to three different categories of users. The categories are:
owner — The owner of the file or application.
group — The group that owns the file or application.
everyone — All users with access to the system.
As stated earlier, it is possible to view the permissions for a file by invoking a long format listing with the command ls -l. For example, if the user juan creates an executable file named foo, the output of the command ls -l foo would look like this:
-rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo |
The permissions for this file are listed at the start of the line, beginning with rwx. This first set of symbols define owner access — in this example, the owner juan has full access, and may read, write, and execute the file. The next set of rwx symbols define group access (again, with full access), while the last set of symbols define the types of access permitted for all other users. Here, all other users may read and execute the file, but may not modify it in any way.
One important point to keep in mind regarding permissions and user accounts is that every application run on Red Hat Linux runs in the context of a specific user. Typically, this means that if user juan launches an application, the application runs using user juan's context. However, in some cases the application may need a more privileged level of access in order to accomplish a task. Such applications include those that edit system settings or log in users. For this reason, special permissions have been created.
There are three such special permissions within Red Hat Linux. They are:
setuid — used only for applications, this permission indicates that the application is to run as the owner of the file and not as the user executing the application. It is indicated by the character s in place of the x in the owner category. If the owner of the file does not have execute permissions, the S is capitalized to reflect this fact.
setgid — used primarily for applications, this permission indicates that the application is to run as the group owning the file and not as the group of the user executing the application.
If applied to a directory, all files created within the directory are owned by the group owning the directory, and not by the group of the user creating the file. The setgid permission is indicated by the character s in place of the x in the group category. If the group owner of the file or directory does not have execute permissions, the S is capitalized to reflect this fact.
sticky bit — used primarily on directories, this bit dictates that a file created in the directory can be removed only by the user that created the file. It is indicated by the character t in place of the x in the everyone category. If the everyone category does not have execute permissions, the T is capitalized to reflect this fact.
Under Red Hat Linux, the sticky bit is set by default on the /tmp/ directory for exactly this reason.
6.3.1.1. Usernames and UIDs, Groups and GIDs
In Red Hat Linux, user account and group names are primarily for peoples' convenience. Internally, the system uses numeric identifiers. For users, this identifier is known as a UID, while for groups the identifier is known as a GID. Programs that make user or group information available to users translate the UID/GID values into their more human-readable counterparts.
 | Important |
|---|---|
UIDs and GIDs must be globally unique within your organization if you intend to share files and resources over a network. Otherwise, whatever access controls you put in place will fail to work properly, as they are based on UIDs and GIDs, not usernames and group names. Specifically, if the /etc/passwd and /etc/group files on a file server and a user's workstation differ in the UIDs or GIDs they contain, improper application of permissions can lead to security issues. For example, if user juan has a UID of 500 on a desktop computer, files juan creates on a file server will be created with owner UID 500. However, if user bob logs in locally to the file server (or even some other computer), and bob's account also has a UID of 500, bob will have full access to juan's files, and vice versa. Therefore, UID and GID collisions are to be avoided at all costs. |
There are two instances where the actual numeric value of a UID or GID has any specific meaning. A UID and GID of zero (0) are used for the root user, and are treated specially by Red Hat Linux — all access is automatically granted.
The second instance is that UIDs and GIDs below 500 are reserved for system use. Unlike UID/GID zero (0), UIDs and GIDs below 500 are not treated specially by Red Hat Linux. However, these UIDs/GIDs are never to be assigned to a user, as it is likely that some system component either currently uses or will use these UIDs/GIDs at some point in the future. For more information on these standard users and groups, see the chapter titled Users and Groups in the Red Hat Linux Reference Guide.
When new user accounts are added using the standard Red Hat Linux user creation tools, the new user accounts are assigned the first available UID and GID starting at 500. The next new user account is assigned UID/GID 501, followed by UID/GID 502, and so on.
A brief overview of the various user creation tools available under Red Hat Linux occurs later in this chapter. But before reviewing these tools, the next section reviews the files Red Hat Linux uses to define system accounts and groups.
6.3.2. Files Controlling User Accounts and Groups
On Red Hat Linux, information about user accounts and groups are stored in several text files within the /etc/ directory. When a system administrator creates new user accounts, these files must either be edited by hand or applications must be used to make the necessary changes.
The following section documents the files in the /etc/ directory that store user and group information under Red Hat Linux.
6.3.2.1. /etc/passwd
The /etc/passwd file is world-readable and contains a list of users, each on a separate line. On each line is a colon delimited list containing the following information:
Username — The name the user types when logging into the system.
Password — Contains the encrypted password (or an x if shadow passwords are being used — more on this later).
User ID (UID) — The numerical equivalent of the username which is referenced by the system and applications when determining access privileges.
Group ID (GID) — The numerical equivalent of the primary group name which is referenced by the system and applications when determining access privileges.
GECOS — Named for historical reasons, the GECOS[1] field is optional and is used to store extra information (such as the user's full name). Multiple entries can be stored here in a comma delimited list. Utilities such as finger access this field to provide additional user information.
Home directory — The absolute path to the user's home directory, such as /home/juan/.
Shell — The program automatically launched whenever a user logs in. This is usually a command interpreter (often called a shell). Under Red Hat Linux, the default value is /bin/bash. If this field is left blank, /bin/sh is used. If it is set to a non-existent file, then the user will be unable to log into the system.
Here is an example of a /etc/passwd entry:
root:x:0:0:root:/root:/bin/bash |
This line shows that the root user has a shadow password, as well as a UID and GID of 0. The root user has /root/ as a home directory, and uses /bin/bash for a shell.
For more information about /etc/passwd, see the passwd(5) man page.
6.3.2.2. /etc/shadow
Because the /etc/passwd file must be world-readable (the main reason being that this file is used to perform the translation from UID to username), there is a risk involved in storing everyone's password in /etc/passwd. True, the passwords are encrypted. However, it is possible to perform attacks against passwords if the encrypted password is available.
If a copy of /etc/passwd can be obtained by an attacker, an attack that can be carried out in secret becomes possible. Instead of risking detection by having to attempt an actual login with every potential password generated by password-cracker, an attacker can use a password cracker in the following manner:
A password-cracker generates potential passwords
Each potential password is then encrypted using the same algorithm as the system
The encrypted potential password is then compared against the encrypted passwords in /etc/passwd
The most dangerous aspect of this attack is that it can take place on a system far-removed from your organization. Because of this, the attacker can use the highest-performance hardware available, making it possible to go through massive numbers of passwords very quickly.
Therefore, the /etc/shadow file is readable only by the root user and contains password (and optional password aging information) for each user. As in the /etc/passwd file, each user's information is on a separate line. Each of these lines is a colon delimited list including the following information:
Username — The name the user types when logging into the system. This allows the login application to retrieve the user's password (and related information).
Encrypted password — The 13 to 24 character password. The password is encrypted using either the crypt(3) library function or the md5 hash algorithm. In this field, values other than a validly-formatted encrypted or hashed password are used to control user logins and to show the password status. For example, if the value is ! or *, the account is locked and the user is not allowed to log in. If the value is !! a password has never been set before (and the user, not having set a password, will not be able to log in).
Date password last changed — The number of days since January 1, 1970 (also called the epoch) that the password was last changed. This information is used in conjunction with the password aging fields that follow.
Number of days before password can be changed — The minimum number of days that must pass before the password can be changed.
Number of days before a password change is required — The number of days that must pass before the password must be changed.
Number of days warning before password change — The number of days before password expiration during which the user is warned of the impending expiration.
Number of days before the account is disabled — The number of days after a password expires before the account will be disabled.
Date since the account has been disabled — The date (stored as the number of days since the epoch) since the user account has been disabled.
A reserved field — A field that is ignored in Red Hat Linux.
Here is an example line from /etc/shadow:
juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:11956:0:90:5:30:12197: |
This line shows the following information for user juan:
The password was last changed September 25, 2002
There is no minimum amount of time required before the password can be changed
The password must be changed every 90 days
The user will get a warning five days before the password must be changed
The account will be disabled 30 days after the password expires if no login attempt is made
The account will expire on May 24, 2003
For more information on the /etc/shadow file, see the shadow(5) man page.
6.3.2.3. /etc/group
The /etc/group file is world-readable and contains a list of groups, each on a separate line. Each line is a four field, colon delimited list including the following information:
Group name — The name of the group. Used by various utility programs as a human-readable identifier for the group.
Group password — If set, this allows users that are not part of the group to join the group by using the newgrp command and typing the password stored here. If a lower case x is in this field, then shadow group passwords are being used.
Group ID (GID) — The numerical equivalent of the group name. It is used by the operating system and applications when determining access privileges.
Member list — A comma delimited list of the users belonging to the group.
Here is an example line from /etc/group:
general:x:502:juan,shelley,bob |
This line shows that the general group is using shadow passwords, has a GID of 502, and that juan, shelley, and bob are members.
For more information on /etc/group, see the group(5) man page.
6.3.2.4. /etc/gshadow
The /etc/gshadow file is readable only by the root user and contains an encrypted password for each group, as well as group membership and administrator information. Just as in the /etc/group file, each group's information is on a separate line. Each of these lines is a colon delimited list including the following information:
Group name — The name of the group. Used by various utility programs as a human-readable identifier for the group.
Encrypted password — The encrypted password for the group. If set, non-members of the group can join the group by typing the password for that group using the newgrp command. If the value of this field is !, then no user is allowed to access the group using the newgrp command. A value of !! is treated the same as a value of ! — however, it also indicates that a password has never been set before. If the value is null, only group members can log into the group.
Group administrators — Group members listed here (in a comma delimited list) can add or remove group members using the gpasswd command.
Group members — Group members listed here (in a comma delimited list) are regular, non-administrative members of the group.
Here is an example line from /etc/gshadow:
general:!!:shelley:juan,bob |
This line shows that the general group has no password and does not allow non-members to join using the newgrp command. In addition, shelley is a group administrator, and juan and bob are regular, non-administrative members.
Since editing these files by hand raises the potential for syntax errors, it is recommended that the applications provided with Red Hat Linux for this purpose be used instead. The next section reviews the primary tools for performing these tasks.
6.3.3. User Account and Group Applications
There are two basic types of applications that can be used when managing user accounts and groups on Red Hat Linux systems:
The graphical User Manager application
A suite of command line tools
For detailed instructions on using User Manager, see the chapter titled User and Group Configuration in the Red Hat Linux Customization Guide.
While both the User Manager application and the command line utilities perform essentially the same task, the command line tools have the advantage of being script-able and are therefore more easily automated.
The following table describes some of the more common command line tools used to create and manage user accounts and groups:
| Application | Function |
|---|---|
| /usr/sbin/useradd | Adds user accounts. This tool is also used to specify primary and secondary group membership. |
| /usr/sbin/userdel | Deletes user accounts. |
| /usr/sbin/usermod | Edits account attributes including some functions related to password aging. For more fine-grained control, use the passwd command. usermod is also used to specify primary and secondary group membership. |
| passwd | Sets passwords. Although primarily used to change a user's password, it also controls all aspects of password aging. |
| /usr/sbin/chpasswd | Reads in a file consisting of username and password pairs, and updates each users' password accordingly. |
| chage | Changes the user's password aging policies. The passwd command can also be used for this purpose. |
| chfn | Changes the user's GECOS information. |
| chsh | Changes the user's default shell. |
Table 6-2. User Management Command Line Tools
The following table describes some of the more common command line tools used to create and manage groups:
| Application | Function |
|---|---|
| /usr/sbin/groupadd | Adds groups, but does not assign users to those groups. The useradd and usermod programs should then be used to assign users to a given group. |
| /usr/sbin/groupdel | Deletes groups. |
| /usr/sbin/groupmod | Modifies group names or GIDs, but does not change group membership. The useradd and usermod programs should be used to assign users to a given group. |
| gpasswd | Changes group membership and sets passwords to allow non-group members who know the group password to join the group. It is also used to specify group administrators. |
| /usr/sbin/grpck | Checks the integrity of the /etc/group and /etc/gshadow files. |
Table 6-3. Group Management Command Line Tools
The tools listed thus far provide system administrators great flexibility in controlling all aspects of user accounts and group membership. To learn more about how they work, refer to the man page for each. These applications do not, however, determine what resources these users and groups have control over. For this, the system administrator must use file permission applications.
6.3.3.1. File Permission Applications
Permissions for files, directories, and applications are an integral part of managing resources within an organization. The following table describes some of the more common command line tools used for this purpose.
| Application | Function |
|---|---|
| chgrp | Changes which group owns a given file. |
| chmod | Changes access permissions for a given file. It is also capable of assigning special permissions. |
| chown | Changes a file's ownership (and can also change group). |
Table 6-4. Permission Management Command Line Tools
It is also possible to alter these attributes in the GNOME and KDE graphical environments by right-clicking on the desired object and selecting Properties.