Linux with Operating System Concepts

required
entry in the directive is the module itself. All of the modules are stored 
in /
lib64/security
and their names are of the form /
pam_
xxx
.so
where 
xxx
is the 
remainder of their name. If you are using third-party modules or modules that exist in 

---

372
◾
Linux with Operating System Concepts
other libraries, you must specify the full path name. Otherwise, the path (/lib64/security) 
may be omitted. The module name is replaced by a configuration file name if the control 
flag is included.
Some modules utilize arguments as further specifications in the configuration state-
ments. After the module name, it is permissible to include parameters such as tests passed 
on to the module so that the module has additional values to work with. For instance, you 
might have a condition such as 
uid 
<
500
or 
user !
=
root
. Parameters can themselves 
be followed by an option. Options include terms such as 
quiet
, 
revoke
, 
force
, 
open
, 
close
, and 
auto_start
.
9.5.3 An Example Configuration File
We wrap up this section by looking at one of the default /etc/pam.d configuration files. 
Here, we look at the one provided for su (to change user).
auth 
sufficient pam_rootok.so
auth include system–auth
account 
sufficient 
pam_succeed_if.so uid
=
0 use_uid quiet
account include 
system–auth
password include 
system–auth
session include 
system–auth
session optional pam_xauth.so
This configuration file authenticates the user using 
pam_rootok.so
. If this module 
succeeds, then the sufficient flag is met and no further authentication attempts are neces-
sary. If this fails, then the su program moves on to the next step in authentication, which is 
to utilize the auth components found in the system-auth configuration file. This is shown 
below.
auth 
required pam_env.so
auth 
sufficient pam_fprintd.so
auth 
sufficient 
pam_unix.so nullok try_first_pass
auth 
requisite 
pam_succeed_if.so uid 
>=
500 quiet
auth 
required pam_deny.so
If we succeed in making it through 
system-auth
’s authentication phase, the next 
step is su’s account stack. Here, we have a sufficient directive. If 
pam_succeed_if.so
is 
successful, then we move on to the password directive; otherwise, we invoke system-auth’s 
account stack. We see that the password directive calls upon system-auth’s password stack. 
Finally, there are two session directives. The first, again, calls upon system-auth followed 
by an optional directive. In this case, the module, 
pam_xauth.so
, executes but its suc-
cess or failure status is immaterial.
Older versions of PAM used a single configuration file, /
etc/pam.conf
. In this file, 
the directives had an additional field at the beginning that listed the application such as 
su, login, or poweroff. If your version of PAM allows for separate configuration files (as we 

---

User Accounts
◾
373
assumed here), then the pam.conf file will be ignored. For more information on PAM, you 
should explore the PAM documentation that comes with your particular dialect of Linux. 
It is best not to alter any configuration files unless you have a clear understanding not only 
of PAM configuration but also of each of the modules involved.
9.6 ESTABLISHING COMMON USER RESOURCES
For a system administrator, creation of accounts can be a tedious task. For instance, in a 
large organization, the system administrator may find that he or she is creating dozens 
or hundreds of accounts at a time and perhaps has to do this weekly or monthly. A shell 
script to automate the process is only one feature that the system administrator will want 
to employ. There are other mechanisms to help establish user accounts, including the auto-
matic generation of user files and the establishment of environment variables and aliases. 
These items are all controlled by the system administrator.
9.6.1 Populating User Home Directories with Initial Files
The /
etc/skel
directory is, by default, the directory that the system administrator will 
manipulate to provide initial files for the user. Anything placed in this directory is copied 
into the new user’s home directory when the directory is generated. The only change made 
to these items is the owner and group, which are altered from root to the user’s username 
and private group name. Typically, the files in /etc/skel will be limited to user shell startup 
files (e.g., .
bashrc
) and common software configuration files and subdirectories (e.g., 
.
mozilla/
). Your installation of CentOS will probably have two or three files of .
bashrc
, 
.
bash_profile
, and maybe .
bash_logout
, along with two subdirectories with initial 
contents of .
gnome2
and .
mozilla
.
The system administrator is encouraged to keep the startup files small and place system-
oriented startup instructions in the startup files in /etc such as /
etc/bashrc
and /
etc/
profile
. This makes it far easier for the administrator to update startup values like envi-
ronment variables.
Consider defining an environment variable for the default text editor. This is called 
EDITOR. As a system administrator, you can define EDITOR either in /etc/bashrc (or 
/etc/profile) or in /etc/skel/.bashrc, or some other similar file that is automatically gener-
ated for each user. Let us assume you place this in /etc/skel/.bashrc as 
EDITOR
=
/bin/
vi
. After hundreds of user accounts have been generated, you decide to replace vi with 
vim. Now, not only do you have to modify the /etc/skel/.bashrc file to be 
EDITOR
=
/bin/
vim
, you also have to modify the hundreds of users’ .bashrc files. Instead, placing this 
command in /etc/bashrc allows you to make just one modification and have it affect all 
users (or at least all users who run Bash). Alternatively, you could create a symbolic link 
to map vi to vim, but this solution would not be effective if you decided to change from 
vi to emacs.
The .bash_profile file will usually consist of just a few items. The file begins with an if-
then statement testing if the user’s .bashrc file exists and if so, executes it. Thus, the if-then 
statement orders the execution of the two files. While .bash_profile begins first, .bashrc is 
then executed before the remainder of .bash_profile executes.

---

374
◾
Linux with Operating System Concepts
The last two instructions in the .bash_profile file add 
$HOME/bin
to the user’s PATH 
variable and then exports the new version of PATH. The added directory is the user’s home 
path followed by /bin, as in /
home/foxr/bin
. This is added so that users who wish to cre-
ate their own executable programs (or who downloaded and installed executables in their 
own home directory space) can reference those programs without using a path.
The .bash_profile file typically consists of the following instructions:
if [ -f ~/.bashrc ]; then
. ~./bashrc
fi
PATH
=
$PATH:$HOME/bin
export PATH
The .bashrc program may initially have only the following statement. This instruction 
tests for the availability of the file /etc/bashrc and if it exists, it is executed.
if [ -f/etc/bashrc ]; then
. /etc/bashrc
fi
The user is free to modify and add to either or both of .bash_profile and .bashrc. It 
is the system administrator who would modify /etc/bashrc (as well as /etc/profile). The 
user might for instance add further environment variables to either .bash_profile or 
.bashrc. The user can define aliases in either of these files, unalias system-wide aliases 
(although this is not a particularly good idea), and place commands to execute their 
own scripts.
The /etc startup script files are far more involved than the .bash_profile and .bashrc 
files. These include /
etc/bashrc
, /
etc/profile
, /
etc/csh.cshrc
, and /
etc/
csh.login
. The /etc/profile script is executed whenever a user logs in, irrelevant of 
whether the log in is GUI or command-line based and irrelevant of any shell utilized. 
This script first creates a PATH variable. This variable is established based on the type of 
user (system administrator or other). Included in the path will be /
sbin
, /
usr/sbin
, /
usr/local/sbin
for root, or /
bin
, /
usr/bin
, /
usr/local/bin
for normal users, 
among other directories. The variables USER, LOGNAME, MAIL, HISTCONTROL, 
HISTSIZE, and HOSTNAME are established and exported. Next, 
umask
is set (dis-
cussed in the next subsection). Finally, the .
sh
scripts in /
etc/profile.d
are exe-
cuted. Most of these files establish further environment variables related to the type 
of terminal (or GUI) being used, the language of the user, and specific software (e.g., 
vi). The system administrator can add further variables and aliases to the /etc/profile 
startup script.
The /etc/bashrc script will be executed by the user’s own .bashrc script. The /etc/bashrc 
script is the primary mechanism whereby the system administrator will enforce startup 
features, including bash-specific variables and aliases.

---

User Accounts
◾
375
The order that these files execute is based on the situation. Upon logging in and starting 
a bash shell, the behavior is
/etc/profile 
→
~/.profile (if it exists) 
→
~/.bash_profile 
→
~/.bashrc 
→
/etc/bashrc
If the user opens a new bash shell, then the process is: ~./bashrc 
→
/etc/bashrc. If the user 
logs in to a non-Bash session, /etc/profile and ~/.profile execute, but then either no further 
scripts execute, or scripts specific to that shell might execute (e.g., ~/.cshrc,/etc/csh.cshrc).
9.6.2 Initial User Settings and Defaults
One of the steps that /etc/profile performs is the establishment of the umask value. The 
umask instruction sets the default file permissions. Whenever a file or directory is cre-
ated, its initial permissions are dictated by the 
umask
value. The umask instruction is set 
for each user. In /etc/profile, we want to establish a umask value dependent on whether 
the user is root or anyone else. This allows us to have one default for root and one for any 
other user. The format for umask is 
umask