-->
Previous Table of Contents Next


Performing Backups

Few issues that the typical Linux administrator deals with are as important as the backup or archiving of a system. An administrator can be fired or a company can literally fail because of the loss of valuable data. The disk or disks on a computer are electromechanical devices, and they will fail at some time.

Most new hard disks are rated at around 150,000 hours mean time between failures—more than five years. But the mean-time statistic can be deceptive. Your disk could fail at the 50,000 hour mark or it might last for more than 10 years (highly unlikely). You’re gambling if you back up your systems only occasionally, and you take an even greater chance if you aren’t checking your backup tapes regularly.


See “Planning a Backup Schedule,” p. 227

PAM: The Pluggable Authentication Modules Architecture

Users need to be able to perform the tasks they want, even if their desired goal is winning that game of Solitaire. In order to do this, users will affect the system and its contents in varying degrees. In general, users should be able to run applications and create, change and delete files that do not affect the system’s continued performance or change items belonging to another user that that user has not decided to share. One way of assigning authority over a system is based on your login name and password combination: When you log in, the system asks you for a name and password. Based on the proof that you are who you say you are, the system allows you to do essentially anything you want to your own area of the system and restricts you if you try to affect a part of the system you’re not supposed to.

Other methods exist for verifying a user’s identity besides the name-password combination. The Pluggable Authentication Modules (PAM) architecture allows you to change authentication policy without having to change the applications themselves. This section presents the structure and relationship of the PAM module architecture.

These are the four types of PAM modules:

  Auth performs the authentication activity.
  Account defines if the authentication is allowed. For example, consider a user who’s only supposed to be on the system during the daytime and not work evenings or weekends. An account module would detect the user if she attempted to perform an action in the middle of the night.
  Password sets passwords.
  Session provides services to the user after the account module allows the authentication module to verify the user’s identity.

Modules may be stacked in sequence to allow multiple methods of access or to restrict access by requiring success of multiple methods.

Understanding PAM Configuration Files

The configuration files for PAM are located in the directory /etc/pam.d/.


NOTE:  In older Linux systems, the file /etc/pam.conf provided configuration definitions. /etc/pam.conf is still supported for backwards compatibility, but its use is discouraged.

The best way to understand the syntax is to examine a configuration file. Here’s the PAM file for passwd. If you installed PAM as part of your Linux installation, this is the default file /etc/pam.d/passwd:


#%PAM-1.0

auth       required     /lib/security/pam_pwdb.so shadow nullok

account    required     /lib/security/pam_pwdb.so

password   required     /lib/security/pam_cracklib.so retry=3

password   required     /lib/security/pam_pwdb.so use_authtok nullok

Line 1 is a comment, indicated by the octothorp (# sign) at the beginning of the line. Line two causes the user to be prompted to enter a password and for that password to be checked. The third line does the same if shadow passwords aren’t being use (more on shadowing later). Line four calls a password-cracking application to see if the new password is a good one, and line five specifies which module should be used to change the password.

Required, Requisite, and Optional: Module Order and Necessity

You can see that all four of the called modules are marked as “required.” Labeling a module as required means that that module is called regardless of the success or failure of earlier modules. As a security guideline, all of them are called, so the reply from a failure at any point looks the same. By hiding the location of the failure, a malicious attacker’s task is made harder.

If every module is required, the order of the modules is unimportant. However, PAM allows for these other control flags to be used instead of required:

  Optional
  Sufficient
  Requisite

“Optional” is entirely secondary to all other modules; the success or failure of an optional module does not affect the success of the authentication, IF there is another module in the PAM configuration file. If an optional module is the only one defined for authentication, its success or failure determines the success or failure of the authentication itself. A “sufficient” module acts like an optional module, except it overrides any or all optional modules. A required or requisite module’s response supersedes a sufficient module, however. If a “requisite” module fails, control is directly returned to the application. If you want a PAM stack to stop at a particular module, you can edit the configuration file and change the control flag from required to requisite.

For more information, Red Hat Software provides documentation for PAM on its Web site at http://www.redhat.com/linux-info/pam/.


Previous Table of Contents Next