![]() |
|
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 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.
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:
Table 1. R�sum� de la cha�ne d'ex�cution PAM
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.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>.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:11