14.3. Format des fichiers de configuration PAM

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

<interface-module>  <indicateur-contrôle>   <chemin-module>   <arguments-module>

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

14.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 a être défini. Par exemple, une ligne typique d'une configuration pourrait ressembler à l'extrait suivant:

auth      required  /lib/security/pam_unix.so

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

14.3.1.1. Modules d'empilage

Les directives des interfaces de modules peuvent être empilées ou placées les une 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     /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

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 non-cryptée 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.

14.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).

14.3.3. Chemins d'accès aux modules

Les chemins d'accès aux modules indiquent à PAM où trouver les modules enfichables à utiliser avec l'interface de module spécifiée. Normalement, le chemin d'accès complet du module est indiqué, comme par exemple, /lib/security/pam_stack.so. Cependant, si ce n'est pas le cas, les système suppose que le module spécifié se trouve dans le répertoire /lib/security/, l'emplacement par défaut des modules PAM.

14.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  /lib/security/pam_userdb.so db=<chemin-au-fichier>

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.