Cada archivo de configuración PAM contiene un grupo de directivas formateadas como sigue:
<module interface> <control flag> <module name> <module arguments>
Existen cuatro tipos de módulos PAM usados para controlar el acceso a los servicios. Estos tipos establecen una correlación entre los diferentes aspectos del proceso de autorización:
auth — Estos módulos autentifican a los usuarios pidiendo y controlando una contraseña. Los módulos con esta interfaz también pueden establecer credenciales, tales como pertenencias de grupo o tickets Kerberos.
account — Estos módulos controlan que la autenticación sea permitida (que la cuenta no haya caducado, que el usuario tenga permiso de iniciar sesiones a esa hora del día, etc.).
password — Estos módulos se usan para establecer y verificar contraseñas.
session — Estos módulos configuran y administran sesiones de usuarios. Los módulos con esta interfaz también pueden realizar tareas adicionales que son necesitadas para permitir acceso, como el montaje de directorios principales de usuarios y hacer el buzón de correo disponible.
Un módulo individual puede proporcionar alguno o todas las interfaces de módulos mencionadas anteriormente. Por ejemplo, pam_unix.so tiene componentes que direccionan las cuatro interfaces.
En un archivo de configuración PAM, la interfaz del módulo es el primer aspecto a definir. Por ejemplo, una línea típica de una configuración sería:
auth required /lib/security/pam_unix.so
Esto provoca que PAM compruebe el componente pam_unix.so del módulo auth.
Las directivas de interfaces de módulos pueden ser definidas unas sobre otras (apiladas) para que se puedan usar varios módulos para un mismo propósito. El orden de una pila de módulos es muy importante en el proceso de autenticación.
El hecho de apilarlos hace que sea más fácil que el administrador exija diversas condiciones antes de permitir la autentificación del usuario. Por ejemplo, rlogin normalmente usa cinco módulos auth, como se puede ver en el archivo de configuración de PAM:
auth required /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth
Antes de que a alguien se le permita llevar a cabo el rlogin, PAM verifica que el archivo /etc/nologin no exista, que no esté intentando iniciar una sesión en modo remoto como root y que se pueda cargar cualquier variable de entorno. Entonces se lleva a cabo una autenticación rhosts exitosa antes que se permita la conexión. Si falla la autenticación rhosts entonces se lleva a cabo una autenticación de contraseña estándar.
Todos los módulos PAM generan un resultado de éxito o fracaso cuando se les llama. Los indicadores de control le dicen a PAM qué hacer con el resultado. Como los módulos pueden apilarse en un determinado orden, los indicadores de control le dan la posibilidad de fijar la importancia de un módulo con respecto al objetivo final del proceso de autenticación para el servicio.
Hay cuatro indicadores de control definidos:
required — El resultado del módulo debe ser exitoso para que la autenticación continue. Si un módulo required falla, el usuario no es notificado hasta que los resultados en todos los módulos referenciandos por esa interfaz sean completados.
requisite — El resultado del módulo debe ser exitóso para que la autenticación continue. Sin embargo, si el resultado de un módulo requisite falla, el usuario es notificado inmediatamente con un mensaje reflejando el primer módulo required o requisite fracasado.
sufficient — El resultado del módulo es ignorado si falla. Pero si el resultado del módulo con el indicador sufficient es exitoso y ningún módulo con indicador required ha fallado, entonces no se requiere ningún otro resultado y el usuario es autenticado para el servicio.
optional — Se ignora el resultado del módulo si falla. Si el resultado del módulo es exitoso, no juega ningún papel en el éxito o fracaso general para el módulo. Un módulo con un indicador optional es necesario para la autenticación exitosa cuando no hay otros módulos referenciando la interfaz. En este caso, un módulo optional determina la autenticación PAM para esa interfaz.
El orden en el cual se llaman los módulos required no es crítico. Los indicadores de control sufficient y requisite provocan que el orden se vuelva importante.
Las rutas de los módulos le indican a PAM dónde encontrar el módulo conectable que hay que usar con el tipo de interfaz de módulo especificada. Generalmente, se proporciona como una ruta completa al módulo, como /lib/security/pam_stack.so. Sin embargo, si no se proporciona la ruta entera, entonces se asume que el módulo está en el directorio /lib/security/, la dirección por defecto de los módulos PAM.
PAM utiliza argumentos para transmitir información a un módulo conectable durante la autenticación para algunos módulos.
Por ejemplo, el módulo pam_userdb.so usa contraseñas almacenads en una base de datos Berkeley DB file para autenticar a los usuarios. La base de datos Berkeley es una base de datos open source incorporada en muchas aplicaciones. El módulo toma un argumento db para que la base de datos Berkeley conozca que base de datos usar para el servicio solicitado.
Una línea típica pam_userdb.so dentro de un archivo PAM es similar a:
auth required pam_userdb.so db=<path-to-file>
En el ejemplo anterior, sustituiremos <path-to-file> con la ruta completa al archivo de base de datos Berkeley.
Los argumentos inválidos se ignoran y no afectan en ningún modo el éxito o fracaso del módulo PAM. Sin embargo, la mayoría de los módulos notificarán un error en el archivo /var/log/messages.