15.3. Format des fichiers de configuration PAM

Chaque fichier de configuration PAM comprend un ensemble de directives établies selon format suivant :

<module interface>  <control flag>   <module name>   <module arguments>

Les sections suivantes décrivent ces éléments un par un.

15.3.1. Interface du module

Il existe quatre types d'interface pour les modules PAM, chacune correspondant à un aspect différent du processus d'autorisation :

NoteRemarque
 

Un module individuel peut fournir une interface de module particulière ou toutes les interfaces de modules. Par exemple, pam_unix.so fournit les quatre interfaces.

Dans un fichier de configuration PAM, l'interface de module est le premier aspect à être défini. Par exemple, une ligne typique d'une configuration pourrait ressembler à l'extrait suivant :

auth      required  pam_unix.so

Cette ligne donne l'instruction aux PAM d'utiliser l'interface auth du module pam_unix.so.

15.3.1.1. Interface du module d'empilage

Les directives des interfaces de modules peuvent être empilées ou placées les unes sur les autres, afin que de multiples modules puissent être utilisés ensemble dans un but particulier. Dans de telles circonstances, l'ordre dans lequel les modules sont répertoriés est très important au niveau du processus d'authentification.

Grâce à l'empilage, un administrateur peut facilement exiger la présence de différentes conditions avant d'autoriser un utilisateur à s'authentifier. Par exemple, rlogin utilise normalement cinq modules auth empilés, comme le montre son fichier de configuration PAM :

auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       sufficient   pam_rhosts_auth.so
auth       required     pam_stack.so service=system-auth

Avant d'accorder l'autorisation d'utilisation de rlogin, PAM s'assure que le fichier /etc/nologin n'existe pas, que l'utilisateur n'essaie pas de se connecter à distance en tant que super-utilisateur (ou root) au moyen d'une connexion réseau et que toutes les variables d'environnement peuvent être chargées. Si une authentification rhosts peut être établie avec succès, la connexion est alors autorisée. En revanche, si l'authentification rhosts échoue, une authentification standard de mot de passe est exécutée.

15.3.2. Indicateurs de contrôle

Lorsqu'ils sont appelés, tous les modules PAM donnent un résultat indiquant soit la réussite, soit l'échec. Les indicateurs de contrôle indiquent aux PAM comment traiter ce résultat. Étant donné que les modules peuvent être empilés dans un ordre bien précis, les indicateurs de contrôle décident de l'importance de la réussite ou de l'échec d'un module spécifique par rapport au but général d'authentification d'un utilisateur pour un service donné.

Il existe quatre types d'indicateurs de contrôle prédéfinis, à savoir :

ImportantImportant
 

L'ordre dans lequel les modules required sont appelés n'est pas primordial. Les modules portant l'indication sufficient et requisite en revanche, donnent à l'ordre une importance vitale.

Il existe désormais pour PAM une nouvelle syntaxe d'indicateurs de contrôle offrant un contrôle encore plus précis. Veuillez lire les documents PAM figurant dans le répertoire /usr/share/doc/pam-<numéro-de-version>/ pour obtenir des informations sur cette nouvelle syntaxe (où <numéro-de-version> correspond au numéro de version de PAM).

15.3.3. Nom de module

Le nom de module donne à PAM le nom du module enfichable contenant l'interface de module spécifiée. Dans les versions plus anciennes de Red Hat Enterprise Linux, le chemin entier du module était fourni dans le fichier de configuration PAM, comme /lib/security/pam_stack.so. Toutefois, depuis l'arrivée de systèmes multilib qui stockent des modules PAM de 64-octets dans le répertoire /lib64/security/, le nom du répertoire est omis vu que les applications sont liées à la version appropriée de libpam, qui peut trouver la correcte version du module.

15.3.4. Arguments des modules

PAM utilise des arguments pour transmettre des informations à un module enfichable lors du processus d'authentification de certains modules.

Par exemple, le module pam_userdb.so utilise des indications secrètes stockées dans un fichier de la base de données Berkeley pour authentifier les utilisateurs. La base de données Berkeley est une base de données Open Source intégrée dans de nombreuses applications. Le module nécessite un argument db pour spécifier à la base de données Berkeley quelle base de données précise doit être utilisée pour le service demandé.

Une ligne pam_userdb.so typique d'un fichier de configuration PAM ressemble à l'extrait suivant :

auth      required  pam_userdb.so db=<path-to-file>

Dans l'exemple précédent, remplacez <chemin-au-fichier> par le chemin d'accès complet au fichier de la base de données Berkeley DB.

Les arguments non-valides ne sont pas pris en compte et n'ont aucune incidence sur la réussite ou l'échec du module PAM. Toutefois, la plupart des modules rapporteront une erreur dans le fichier /var/log/messages.