From SpectLog
Jump to: navigation, search

This article contains excerpts from documentation to highlight and summarize key features of PAM.

PAM is a framework to service authentication & authorization requests. The PAM library libpam which apps are linked with uses variety pluggable modules (other dynamic libraries) and configuration files to customize the behaviour. Privilege granting apps like su and login use standard PAM API of libpam to handle such requests.

PAM configuration is only applicable to apps which use PAM in their internal logic. Such apps are commonly called "PAM-aware".

Related files

Collection of libraries:

/lib/security/*
/lib64/security/*

Configuration per library:

/etc/security/*

There could be other configuration files referenced by certain PAM modules. For example, pam_securetty checks /etc/securetty file.

Configuration per app:

/etc/pam.d/*

The configuration files under /etc/pam.d directory usually have the same name as corresponding "PAM aware" app which uses it.

Offline Documentation

Official offline docs:

/usr/share/doc/pam-*
man 5 pam.conf

Module-specific configuration can be found in corresponding man-pages listed by

apropos pam_

Summary

Rules

Configuration per each app uses list = chain of rules. The format of each rule is a space separated collection of tokens:

service    type    control    module-path    module-arguments

The presence of /etc/pam.d directory will cause Linux-PAM to ignore /etc/pam.conf.

Syntax in /etc/pam.d/* files and pam.conf file is different only by service field which is absent in /etc/pam.d/* files.

(IMHO) Just like with chain of rules in IP tables, PAM configuration evolved in a programming language with custom syntax and multitude of keywords (especially those related to module arguments). This all can only be learnt by changing various examples.

Type field

The rules in the lists are "typed" by service request. Types (management groups) of rules:

  • auth - authenticate user
  • account - authorise user
  • session - actions at the beginning and at the end
  • password - update user info (commonly authentication info used by auth)

(IMHO) Although the purpose of each type is defined by explanation, it does not help much in practice without experience.

It is better to think of a stacks per each of the four types: auth-stack, account-stack, session-stack, password-stack. The PAM library calls each of the modules in specified stack type, in turn.

If the type value is prepended with a minus character (-), the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system.

Control field

Each of the modules returns a pass/fail indication to the library. The PAM library combines these pass/fail results into a pass/fail result for the stack as a whole.

Control values (simple syntax):

  • required - Fail makes the stack immediately return fail.
  • requisite - Fail is remembered until the end of the stack to return fail.
  • sufficient - Pass makes the stack immediately return pass.
  • optional - Result is ignored.
  • include - Calls stack from specified file (similar to C-style #include directive - see man 5 pam.conf)
  • substack - Calls stack from specified file (similar to function call in any language - see man 5 pam.conf)

There are two types of syntax for this control field. The simple one has a single simple keyword. The complex one involves a square-bracketed selection of value=action pairs:

[value1=action1 value2=action2 ...]

Each of the four keywords have an equivalent expression in terms of the complex syntax (see man 5 pam.conf).

Module path and arguments

Module path is simply location to the shared library containing implementation (by default location is relative to /lib*/security/). Module arguments are obviously module-specific with description in corresponding man-page.

Note that if you wish to include spaces in an argument you should surround that argument with square brackets.

References