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.
Comme expliqué dans Section 4.1, « 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 Section 3.1, « Mécanismes et primitives ».
De même, le drapeau de contrôle est l'un des quatre mots clef décrits dans Section 3.3, « 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.
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:
PAM_SUCCESS | PAM_IGNORE | other | |
---|---|---|---|
binding | if (!fail) break; | - | fail = true; |
required | - | - | fail = true; |
requisite | - | - | fail = true; break; |
sufficient | if (!fail) break; | - | - |
optional | - | - | - |
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
.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.