PAM (Pluggable Authentication Modules) provides an interface that programs can use to connect to whatever authentication methods are desired. Authentication can be as trivial as the user typing "hello world", as complex as biometrics, or as prosaic as passwords. I think PAM is a great boon for system administrators, and I'm excited to see it in CVS.
PAM works by having the system administrator define which modules she wants run for each application. The application calls PAM, PAM checks its configuration files, and then PAM calls the relevant modules. If the module requires additional data (such as a password), the module requests it from PAM, and PAM requests it from the application, then hands it to the module. The module runs, and reports its results to PAM.
PAM combines the results of all the modules it's configured to run for the application, and then returns a single combined success or failure to the application, depending on a strict set of criteria. The criteria are also configured by the system administrator.
At the moment, PAM support in CVS is experimental, and is limited to the fallback option in the pserver connection method. To get PAM support for CVS, configure your CVS executable with --enable-pam, having SystemAuth set to yes in your CVSROOT/config file, and leave CVSROOT/passwd empty.
The default PAM configuration file for CVS is /etc/pam.d/cvs. If your version of PAM uses a single /etc/pam.conf file instead of a separate file for each application, the application name is cvs. The PAM application name (or configuration file name) can be configured at compilation time with -with-hardcoded-pam-service-name=name. Use ./configure to set the PAM compilation options. Make sure you read the INSTALL file in the CVS source code, and the installation instructions in Chapter 2.
Each PAM configuration file contains a series of lines. Those lines have the format module-type control-flag module-path arguments. The module type defines the aspect of authentication that the line controls. The module path and arguments control what is done for that line. The control flag specifies how PAM should react to the results of the module defined in the module path.
CVS uses the auth, account, and session module types, but not passwd. This means that the system administrator will be responsible for defining and updating the authentication token for each user. The module types are:
PAM can call any number of modules for each module type, but calls only one module type at a time: it will call all auth modules when CVS is identifying the user, or all session modules when CVS is starting a connection. The control-flag for each module controls how PAM calculates success or failure for that module, and for the stack of all modules of the type. If you're accustomed to using PAM, there's a complicated syntax for the control flags that gives you truly fine-grained control. If not, use these four flags:
A basic PAM configuration might be:
account required /usr/lib/security/pam_unix.so auth requisite /usr/lib/security/pam_nologin.so auth required /usr/lib/security/pam_unix.so session required /usr/lib/security/pam_unix.so
PAM has hundreds of modules available, including modules to authenticate users via LDAP or Kerberos, cryptography cards and buttons, or classic Unix authentication. Every time I look, there are even more interesting and useful modules. I use the Linux-PAM web site at http://www.kernel.org/pub/linux/libs/pam/, but you can also find out about PAM news at http://www.openwall.com/pam/ or http://www.sun.com/software/solaris/pam/.
If you use the PAM system, or have comments about it, please consider mailing them at the CVS mailing lists: email@example.com or firstname.lastname@example.org. The developers are actively requesting feedback.