Linux with Operating System Concepts

Option
Meaning
-d
Disable the password (make the account passwordless)
-i 
day
Same as chage -I 
day
-k
Only modify the password if it has expired
-l
Lock the account (user cannot login until unlocked)
-n 
day
Same as chage -m 
day
-S
Output status of password for the given account, similar to chage -l
-u
Unlock the locked account
-x 
day
Same as chage -M 
day
-w 
day
Same as chage -W 
day

---

370
◾
Linux with Operating System Concepts
you can further tailor the user accounts. For instance, we might want to give some users 
the default shell but other users may want other shells.
9.5 PAM
PAM
(or 
pam
) is short for pluggable authentication module. Programs that deal with 
authentication in any form (chage, passwd, su, sudo, login, ssh, etc.) need to handle activi-
ties such as obtaining the password from the user, authenticate the username and pass-
word with a password file, maintain a session, and log events. Rather than requiring that 
a programmer define these operations in every program, we can make a series of library 
modules available, each module is capable of handling some aspect of authentication. We 
then need a mechanism to specify which functions of which modules a given application 
will call upon.
9.5.1 What Does PAM Do?
The idea behind PAM is that it is an 
extensible
piece of software. As a system administrator, 
you configure how a given authentication program will perform its authentication duties 
through a configuration file. The configuration file lists for the various applications’ duties 
which modules to call upon. You can add your own modules or third-party modules to PAM.
Let us consider as an example the passwd program. This program requires that the 
user authenticate before changing their password. This is a two-step process of obtaining 
a password from the user and authenticating the password. It then inputs a new password 
from the user and uses this to modify the /etc/shadow file.
Another program that requires user authentication is 
login
which is called whenever 
a user attempts to log in from either the GUI or a text-based session. The login program 
requires more of PAM than passwd by first authenticating and checking that the account 
is appropriate in this setting as with passwd, but then maintaining a session. The session 
starts once the account is tested and terminates only when the user logs out or when a situ-
ation arises requiring that the user log out. In addition, the session maintains the user’s 
namespace within the user’s context (i.e., the session is run under the PID of the user with 
the user’s access rights).
The strength of PAM is in the modules that implement the functions responsible for 
authentication operations. One function is called 
pam_open_session()
which can be 
invoked through the module 
pam_unix_session.so
. The collection of modules pro-
vides the proper support for most programs that require authentication. It is up to the 
system administrator to tie together those modules that will be used for the given program. 
Additionally, programmers can define their own modules for inclusion. Thus, a system 
that needs a specific module not available in PAM can be added (once written) and then 
used as the system administrator sees fit.
9.5.2 Configuring PAM for Applications
In order to configure PAM, the system administrator will create a configuration file for 
each program that will utilize some part of PAM. These files are placed in the directory 
/
etc/pam.d
. If you take a look in this directory, you will see already-existing configuration 

---

User Accounts
◾
371
files for a number of programs such as atd and crond, sshd, login and passwd, reboot, halt 
and poweroff, and su (we will cover some of these programs in upcoming chapters). These 
configuration files consist of directives that specify the steps that the program needs to 
take with respect to using the various modules of PAM. These directives will consist of 
three parts: the module’s type, a control flag, and the module’s filename.
There are four module types. The 
auth
type invokes the appropriate module to obtain 
the user’s password and match it against whatever stored password file exists. Most mod-
ules are capable of using the /etc/shadow file while other modules might call upon other 
password files if authentication is being performed for accounts other than the login 
account (such as a software-specific account that might be found with an Oracle database).
The 
account
module type handles account restrictions such as whether access is 
allowed based on a time of day or the current status of the system. The 
session
type 
maintains a user session, handling tasks such as logging the start and end of session, 
confirming that the session is still open (so that a repeat login is not required) or even 
maintaining a remotely mounted file system. The 
password
type deals with changing 
passwords, as with the passwd command.
The configuration file might include several directives with the same module type. 
These are known as a 
stack
. Within a stack, we have the possibility that all of the modules 
must run and succeed or that only some of them have to succeed. The control flag is used 
to indicate what pattern of modules needs to succeed.
There are again four types or values for control flags. With 
requisite
, the given mod-
ule must succeed for access to be permitted. If the module fails, control is returned to 
the application to deal with the failure and decide how to proceed. The next control flag 
type is 
required
. If multiple directives within a stack are listed as required, then all of 
the corresponding modules must succeed or else control is returned to the application to 
determine how to proceed with the failure. If there is only one directive in a stack, you 
could use requisite or required. The third control flag type is 
sufficient
. Here, if any 
single module succeeds within the stack of sufficient directives, then success is passed on to 
the application. Thus, a stack of required directives acts as a logical AND operation while 
a stack of sufficient directives acts as a logical OR operation. The last control flag type is 
optional
which does not impact the application but can be applied to perform other 
tasks. For instance, an optional directive whose module succeeds might be used to perform 
logging. Should that module fail, it does not return a failure to the application but logging 
would not take place.
As configurations are available for a number of applications, you can “piggy-back” on 
prior configurations. This is accomplished using the 
include
statement in place of a con-
trol flag. The configuration file 
system-auth
is utilized in a number of different config-
uration files, including 
chfn
, 
chsh
, 
gdm
, 
gdm-autologin
, 
gnome-screensaver
, 
and 
login
. This prevents a system administrator from having to recreate the same strat-
egy over and over again.
The last