PAM (Pluggable Authentication Module) gives system administrators the
flexibility of choosing any authentication service available on
the system to perform authentication. The framework interface is implemented
by the library /usr/lib/libpam.1 and new authentication service
modules can be plugged in and made available without modifying the
applications. The authentication services are implemented by their own
loadable modules whose paths are specified through the /etc/pam.conf and /etc/pam_user.conf files.
In order for PAM to support multiple instruction set architectures
(i.e. 32/64-bit IPF/PA), the Corrigendum U039 of the PAM
Standard is implemented in HP-UX 11i Version 1.5 (B.11.20) (see http://www.opengroup.org/pubs/corrigenda/u039f.htm).
The standard does not allow mixing of 32/64-bit (for example, a
32-bit application cannot execute 64-bit library code).
The format of the /etc/pam.conf and /etc/pam_user.conf files and the paths of the pluggable service authentication
modules have changed. The paths have not changed for 32-bit PAM
libraries for PA architecture. New paths are assigned for new architectures
supported starting with the this release. The new paths are for
32-bit IPF PAM libraries, 64-bit IPF PAM libraries,
and 64-bit PA libraries.
 |
 |  |
 |
 | NOTE: 64-bit PAM support is not yet available for IPF and
PA. |
 |
 |  |
 |
The new pam.conf and pam_user.conf files also support the $ISA token as
defined by Corrigendum U039.
Here is the new pam.conf file (note the comment):
 |
============================================================================== # # PAM configuration # # Authentication management # Note: For PA applications, /usr/lib/security/libpam_unix.so.1 is a # symbolic link that points to the corresponding PA PAM module. # # login auth required /usr/lib/security/$ISA/libpam_unix.so.1 su auth required /usr/lib/security/$ISA/libpam_unix.so.1 dtlogin auth required /usr/lib/security/$ISA/libpam_unix.so.1 dtaction auth required /usr/lib/security/$ISA/libpam_unix.so.1 ftp auth required /usr/lib/security/$ISA/libpam_unix.so.1 OTHER auth required /usr/lib/security/$ISA/libpam_unix.so.1 # # Account management # login account required /usr/lib/security/$ISA/libpam_unix.so.1 su account required /usr/lib/security/$ISA/libpam_unix.so.1 dtlogin account required /usr/lib/security/$ISA/libpam_unix.so.1 dtaction account required /usr/lib/security/$ISA/libpam_unix.so.1 ftp account required /usr/lib/security/$ISA/libpam_unix.so.1 # OTHER account required /usr/lib/security/$ISA/libpam_unix.so.1 # # Session management # login session required /usr/lib/security/$ISA/libpam_unix.so.1 dtlogin session required /usr/lib/security/$ISA/libpam_unix.so.1 dtaction session required /usr/lib/security/$ISA/libpam_unix.so.1 OTHER session required /usr/lib/security/$ISA/libpam_unix.so.1 # # Password management # login password required /usr/lib/security/$ISA/libpam_unix.so.1 passwd password required /usr/lib/security/$ISA/libpam_unix.so.1 dtlogin password required /usr/lib/security/$ISA/libpam_unix.so.1 dtaction password required /usr/lib/security/$ISA/libpam_unix.so.1 OTHER password required /usr/lib/security/$ISA/libpam_unix.so.1 ============================================================================ |
 |
Module providers can specify their own absolute path in the /etc/pam.conf and /etc/pam_user.conf files. In addition, the PAM engine library is modified
to detect the $ISA token and the calling application
type. It will then load the correct PAM module that is of the same
architecture as the calling application. For example:
32-bit IPF applications
Loads /usr/lib/security/hpux32/libpam_unix.so.1.
32-bit PA applications
Loads /usr/lib/security/libpam_unix.so.1 which is a link to /usr/lib/security/libpam_unix.1
 |
 |  |
 |
 | NOTE: A calling application must be built for the same architecture
as the PAM service module. |
 |
 |  |
 |
PAM Compatibility |
 |
If the PAM modules install process edits pam.conf or non-32-bit PA versions of the
module are being provided, then this process needs to be adapted
to the new pam.conf file format. If the install process changes pam.conf to the old format, then the PAM modules will not be
available to non-32-bit PA applications (that is, 32-bit IPF support
will NOT be available for users of the PAM module in question unless pam.conf follows the PAM Standard). Also, for PA PAM modules,
the install process must create a symbolic link to the actual PAM
module (for example, the install process for libpam_xyz.1 must create a symbolic called libpam_xyz.so.1 that points to libpam_xyz.1 in the /usr/lib/security directory).