4. Configuration de PAM

4.1. Emplacement des fichiers de configuration

Le fichier de configuration de PAM est traditionnellement /etc/pam.conf. Ce fichier contient toutes les politiques de PAM pour votre système. Chaque ligne du fichier décrit une étape dans une chaîne, tel que nous allons le voir ci-dessous:

login   auth    required        pam_nologin.so  no_warn

Les champs sont respectivement, le service, le nom du mécanisme, le drapeau de contrôle, le nom du module et les arguments du module. Tout champ additionnel est considéré comme argument du module.

Une chaîne différente est construite pour chaque couple service/mécanisme; ainsi, alors que l'ordre des lignes est important lorsqu'il s'agit des mêmes services ou mécanismes, l'ordre dans lequel les différents services et mécanismes apparaissent ne l'est pas -- excepté l'entrée pour le service other, qui sert de référence par défaut et doit être placé à la fin. L'exemple du papier original sur PAM regroupait les lignes de configurations par mécanisme et le fichier pam.conf de Solaris le fait toujours, mais FreeBSD groupe les lignes de configuration par service. Toutefois il ne s'agit pas de la seule possibilité et les autres possèdent aussi un sens.

OpenPAM et Linux-PAM offrent un mécanisme de configuration alternatif où les politiques sont placées dans des fichiers séparés portant le nom du service auquel ils s'appliquent. Ces fichiers sont situés dans /etc/pam.d/ et ne contiennent que quatre champs à la place de cinq -- le champ contenant le nom du service est omis. Il s'agit du mode par défaut dans FreeBSD 4.x. Notez que si le fichier /etc/pam.conf existe et contient des informations de configuration pour des services qui n'ont pas de politique spécifiée dans /etc/pam.d, ils seront utilisés pour ces services.

Le gros avantage de /etc/pam.d/ sur /etc/pam.conf est qu'il est possible d'utiliser la même politique pour plusieurs services en liant chaque nom de service à un fichier de configuration. Par exemple pour utiliser la même politique pour les services su et sudo, nous pouvons faire comme ceci :

# cd /etc/pam.d
# ln -s su sudo

Ceci fonctionne car le nom de service est déterminé a partir du nom de fichier plutôt qu'indiqué à l'intérieur du fichier de configuration, ainsi le même fichier peut être utilisé pour des services nommés différemment.

Un autre avantage est qu'un logiciel tiers peu facilement installer les politiques pour ses services sans avoir besoin d'éditer /etc/pam.conf. Pour continuer la tradition de FreeBSD, OpenPAM regardera dans /usr/local/etc/pam.d pour trouver les fichiers de configurations; puis si aucun n'est trouvé pour le service demandé, il cherchera dans /etc/pam.d/ ou /etc/pam.conf.

Finalement, quelque soit le mécanisme que vous choisissiez, la politique “magique” other est utilisée par défaut pour tous les services qui n'ont pas leur propre politique.

4.2. Breakdown of a configuration line

Comme expliqué dans la section Emplacement des fichiers de configuration, chaque ligne de pam.conf consiste en quatre champs ou plus: le nom de service, le nom du mécanisme, le drapeau de contrôle, le nom du module et la présence ou non d'arguments pour le module.

Le nom du service est généralement, mais pas toujours, le nom de l'application auquelle les règles s'appliquent. Si vous n'êtes pas sûr, référez vous à la documentation de l'application pour déterminer quel nom de service elle utilise.

Notez que si vous utilisez /etc/pam.d/ à la place de /etc/pam.conf, le nom du service est spécifié par le nom du fichier de configuration et n'est pas indiqué dans les lignes de configuration qui, dès lors, commencent par le nom du mécanisme.

Le mécanisme est l'un des quatre mots clef décrit dans la section Mécanismes et primitives

De même, le drapeau de contrôle est l'un des quatre mots clef décrits dans la section Chaînes et politiques et décrit comment le module doit interpréter le code de retour du module. Linux-PAM supporte une syntaxe alternative qui vous laisse spécifier l'action à associer à chaque code de retour possible; mais ceci devrait être évité puisque ce n'est pas standard et étroitement lié à la façon dont Linux-PAM appelle les services (qui diffère grandement de la façon de Solaris et OpenPAM). C'est sans étonnement que l'on apprend qu'OpenPAM ne supporte pas cette syntaxe.

4.3. Politiques

Pour configurer PAM correctement, il est essentiel de comprendre comment les politiques sont interprétées.

Lorsqu'une application appelle pam_start(3) la bibliothèque PAM charge la politique du service spécifié et construit les quatre chaînes de module (une pour chaque mécanisme). Si une ou plusieurs chaînes sont vides, les chaînes de la politique du service other sont utilisées.

Plus tard, lorsque l'application appelle l'une des six primitives PAM, la bibliothèque PAM récupère la chaîne du mécanisme correspondant et appelle la fonction appropriée avec chaque module listé dans la chaîne. Après chaque appel d'une fonction de service, le type du module et le code d'erreur sont retournés par celle-ci pour déterminer quoi faire. À quelques exceptions près, dont nous parlerons plus tard, la table suivante s'applique:

Si fail est vrai à la fin de la chaîne, ou lorsqu'un “break” est atteint, le dispatcheur retourne le code d'erreur renvoyé par le premier module qui a échoué. Autrement PAM_SUCCESS est retourné.

La première exception est que le code d'erreur PAM_NEW_AUTHOK_REQD soit considéré comme un succès, sauf si aucun module n'échoue et qu'au moins un module retourne PAM_NEW_AUTHOK_REQD le dispatcheur retournera PAM_NEW_AUTHOK_REQD.

La seconde exception est que pam_setcred(3) considère les modules binding et sufficient comme s'ils étaient required.

La troisième et dernière exception est que pam_chauthtok(3) exécute la totalité de la chaîne deux fois (la première pour des vérifications préliminaires et la deuxième pour mettre le mot de passe) et lors de la première exécution il considère les modules binding et sufficient comme s'ils étaient required.