The following sections describe the various features specific to
Red Hat Enterprise Linux that relate to the administration of user accounts and associated
resources.
Under Red Hat Enterprise 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 Enterprise 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 appear 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 Enterprise 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 Enterprise 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 Enterprise Linux, the sticky bit is set by default on the
/tmp/ directory for exactly this
reason.
In Red Hat Enterprise 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 may 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 Enterprise 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 Enterprise 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 Enterprise Linux Reference Guide.
When new user accounts are added using the standard Red Hat Enterprise 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 Enterprise Linux occurs later in this chapter. But before reviewing these
tools, the next section reviews the files Red Hat Enterprise Linux uses to define
system accounts and groups.
On Red Hat Enterprise 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 manually 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 Enterprise Linux.
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 Enterprise 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.
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 Enterprise Linux.
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.
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 manually raises the potential for
syntax errors, it is recommended that the applications provided with
Red Hat Enterprise Linux for this purpose be used instead. The next section reviews
the primary tools for performing these tasks.
There are two basic types of applications that can be used when
managing user accounts and groups on Red Hat Enterprise 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 Enterprise Linux System Administration 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.
File permissions 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. Right-click on the the file's icon (for
example, while the icon is displayed in a graphical file manager or
on the desktop), and select
Properties.
GECOS stands for General
Electric Comprehensive Operating Supervisor. This field was
used at Bell Labs, in the original UNIX implementation. The lab
had many different computers, including one running GECOS. This
field was used to store information when the UNIX system sent
batch and print jobs to the GECOS system.
