Documentation PostgreSQL 7.4.29 | ||||
---|---|---|---|---|
Pr�c�dent | Arri�re rapide | Avance rapide | Suivant |
Quand une application client se connecte au serveur de base de donn�es, elle indique le nom de l'utilisateur PostgreSQL sous lequel elle d�sire se connecter, comme lorsqu'on se connecte sur un ordinateur Unix sous un nom d'utilisateur particulier. Au sein de l'environnement SQL, le nom d'utilisateur de la base de donn�es active d�termine les privil�ges r�gissant l'acc�s aux objets de la base de donn�es -- voir le Chapitre 17 pour plus d'informations. Ainsi, il est essentiel de limiter le nombre des bases de donn�es auxquelles les utilisateurs peuvent se connecter.
L'authentification est le processus par lequel le serveur de bases de donn�es �tablit l'identit� du client et, par extension, par lequel il d�termine si l'application cliente (ou l'utilisateur sous le nom de laquelle elle tourne) est autoris�e � se connecter sous le nom d'utilisateur demand�.
PostgreSQL offre quantit� de m�thodes d'authentification diff�rentes. La m�thode d'authentification d'une connection client particuli�re peut �tre s�lectionn�e d'apr�s l'adresse, la base de donn�es et l'utilisateur de l'h�te client.
Les noms d'utilisateurs PostgreSQL sont s�par�s de fa�on logique des noms d'utilisateurs du syst�me d'exploitation sur lequel tourne le serveur. Si tous les utilisateurs d'un serveur donn� ont aussi des comptes sur la machine serveur, il peut �tre pertinent d'attribuer des noms d'utilisateurs de la base de donn�es qui correspondent aux noms d'utilisateurs du syst�me d'exploitation. Cependant, un serveur qui accepte les connexions distantes peut avoir plusieurs utilisateurs de base de donn�es d�pourvus de compte correspondant sur le syst�me d'exploitation, dans de tels cas il n'y a pas besoin de correspondance entre noms d'utilisateurs de bases de donn�es et noms d'utilisateurs du syst�me d'exploitation.
L'authentification du client est contr�l�e par le fichier pg_hba.conf situ� dans le r�pertoire data, par exemple /usr/local/pgsql/data/pg_hba.conf (HBA signifie <<�host-based authentication�>> : authentification fond�e sur l'h�te.) Un fichier pg_hba.conf par d�faut est install� lorsque le r�pertoire data est initialis� par initdb.
Le format g�n�ral du fichier pg_hba.conf est un ensemble d'enregistrements, un par ligne. Les lignes vides sont ignor�es tout comme n'importe quel texte plac� apr�s le caract�re de commentaire #. Un enregistrement est constitu� d'un certain nombre de champs s�par�s par des espace et/ou des tabulations. Les champs peuvent contenir des espaces si la valeur du champ est mise entre guillemets. Un enregistrement ne peut pas �tre continu� sur plusieurs lignes.
Chaque enregistrement d�termine un type de connexion, une plage d'adresses IP (si appropri� au type de connexion), un nom de base de donn�es, un nom d'utilisateur et la m�thode d'authentification � utiliser pour les connexions correspondant � ces param�tres. Le premier enregistrement correspondant au type de connexion, � l'adresse client, � la base de donn�es demand�e et au nom d'utilisateur est utilis� pour effectuer l'authentification. Il n'y a pas de suite apr�s erreur (<<�fall-through�>> ou <<�backup�>>) : si un enregistrement est choisi et que l'authentification �choue, les enregistrements suivants ne sont pas consid�r�s. Si aucun enregistrement ne correspond, l'acc�s est refus�.
Un enregistrement peut avoir l'un des formats suivants.
local database user authentication-method [authentication-option] host database user IP-address IP-mask authentication-method [authentication-option] hostssl database user IP-address IP-mask authentication-method [authentication-option] hostnossl database user IP-address IP-mask authentication-method [authentication-option] host database user IP-address/IP-masklen authentication-method [authentication-option] hostssl database user IP-address/IP-masklen authentication-method [authentication-option] hostnossl database user IP-address/IP-masklen authentication-method [authentication-option]
La signification des champs est la suivante :
Cet enregistrement intercepte les tentatives de connexion utilisant les sockets du domaine Unix. Sans un enregistrement de ce type, les connections de sockets du domaine Unix ne sont pas permises.
Cet enregistrement intercepte les tentatives de connexion utilisant les r�seaux TCP/IP. Remarquez que les connexions TCP/IP sont d�sactiv�es sauf si le serveur est lanc� avec l'option -i ou si le param�tre de configuration tcpip_socket est activ�.
Cet enregistrement intercepte les tentatives de connexions utilisant SSL sur TCP/IP. Les enregistrements host intercepteront les tentatives de connexion SSL ou non-SSL mais les enregistrements hostssl n�cessitent des connexions SSL.
Pour �tre en mesure de faire usage de cette fonction, le serveur doit �tre compil� avec le support SSL activ�. De plus, SSL doit �tre activ� en positionnant le param�tre de configuration ssl (voir Section 16.4 pour plus d'informations).
Cet enregistrement est similaire � hostssl mais avec une logique oppos�e : il n'intercepte que les tentatives de connexion n'utilisant pas SSL.
Indique quelles bases de donn�es l'enregistrement concerne. La valeur all indique qu'il concerne toutes les bases de donn�es. La valeur sameuser sp�cifie que l'enregistrement n'intercepte que si la base de donn�es demand�e a le m�me nom que l'utilisateur demand�. La valeur samegroup sp�cifie que l'utilisateur demand� doit �tre membre du groupe portant le m�me nom que la base de donn�es demand�e. Sinon, c'est le nom d'une base de donn�es PostgreSQL particuli�re. Des noms de bases de donn�es multiples peuvent �tre fournis en les s�parant par des virgules. Un fichier contenant des noms de bases de donn�es peut �tre indiqu� en faisant pr�c�der le nom de fichier de @. Le fichier doit �tre dans le m�me r�pertoire que pg_hba.conf.
Indique � quels utilisateurs PostgreSQL cet enregistrement correspond. La valeur all indique qu'il concerne tous les utilisateurs. Autrement, c'est le nom d'un utilisateur PostgreSQL particulier. Plusieurs noms d'utilisateurs peuvent �tre fournis en les s�parant avec des virgules. Les noms de groupes peuvent �tre sp�cifi�s en pr�c�dant le nom de groupe du signe +. Un fichier contenant des noms d'utilisateurs peut �tre indiqu� en faisant pr�c�der le nom de fichier du signe @. Le fichier doit �tre dans le m�me r�pertoire que pg_hba.conf.
Ces deux champs contiennent les adresses IP et les masques en notation point�e standard. (Les adresses IP ne peuvent �tre sp�cifi�es que sous forme num�rique, pas sous forme de noms de domaines ou d'h�tes.) Pris s�par�ment, ils sp�cifient les adresses IP des machines clientes que cet enregistrement intercepte. La logique pr�cise est que
(actual-IP-address xor IP-address-field) and IP-mask-field
doit �tre �gal � z�ro pour que l'enregistrement intercepte.
Une adresse IP au format IPv4 correspondra aux connexions IPv6 qui auront l'adresse correspondante. Par exemple, 127.0.0.1 correspondra � l'adresse IPv6 ::ffff:127.0.0.1. Une entr�e donn�e au format IPv6 correspondra uniquement aux connexions IPv6 m�me si l'adresse repr�sent�e est dans le domaine IPv4-vers-IPv6. Notez que les adresses au format IPv6 seront rejet�es si la biblioth�que syst�me C ne supporte pas les adresses IPv6.
Ces champs ne concernent que les enregistrements host, hostssl et hostnossl.
Ce champ peut �tre utilis� � la place de la notation IP-mask notation. C'est un entier pr�cisant le nombre de bits significatifs � placer dans le masque. Le nombre doit �tre compris entre 0 et 32 inclus (dans le cas d'une adresse IPv4) ou 128 inclus (dans le cas d'une adresse IPv6). 0 interceptera toutes les adresses, tandis que 32 (respectivement 128) n'interceptera que l'h�te sp�cifi�. La m�me logique s'applique pour une notation point�e IP-Mask.
Il ne doit pas y avoir d'espace entre l'adresse IP et le / ou le / et le IP-masklen, sinon le fichier ne sera pas analys� correctement.
Ce champ ne concerne que les enregistrements host, hostssl et hostnossl.
D�termine la m�thode d'authentification � utiliser lors d'une connexion via cet enregistrement. Les choix possibles sont r�sum�s ici ; les d�tails se trouvent dans la Section 19.2.
La connexion est permise sans conditions. Cette m�thode permet � n'importe qui de se connecter au serveur de bases de donn�es PostgreSQL, de s'enregistrer comme n'importe quel utilisateur PostgreSQL de son choix sans n�cessiter de mot de passe. Voir la Section 19.2.1 pour les d�tails.
La connexion est rejet�e sans conditions. Ce cas est utile pour <<�filtrer�>> certains h�tes d'un groupe.
Demande au client de fournir un mot de passe encrypt� MD5 pour son authentification. C'est la seule m�thode permettant d'enregistrer les mots de passes encrypt�s dans pg_shadow. Voir la Section 19.2.2 pour les d�tails.
Identique � la m�thode md5 mais utilise une fonction
de cryptage crypt()
plus ancienne, n�cessaire pour les clients
pr�-7.2. On pr�f�rera md5 pour les clients 7.2 et
suivants. Voir Section 19.2.2 pour les d�tails.
Identique � md5, mais le mot de passe est envoy� en texte clair sur le r�seau. Ceci ne devrait pas �tre utilis� sur les r�seaux peu dignes de confiance. Voir Section 19.2.2 pour les d�tails.
Kerberos V4 est utilis� pour authentifier l'utilisateur. Ceci n'est disponible que pour les connexions TCP/IP. Voir Section 19.2.3 pour les d�tails.
Kerberos V5 est utilis� pour authentifier l'utilisateur. Ceci n'est disponible que pour les connexions TCP/IP. Voir Section 19.2.3 pour les d�tails.
R�cup�re le nom de l'utilisateur du syst�me d'exploitation du client (pour les connexions TCP/IP en contactant le serveur d'identification sur le client, pour les connexions locales, en l'obtenant du syst�me d'exploitation.) et v�rifie si l'utilisateur est autoris� � se connecter en tant qu'utilisateur de la base de donn�es demand� en consultant la correspondance indiqu�e apr�s le mot cl� ident.
Si vous utilisez la correspondance sameuser, les noms d'utilisateurs doivent �tre identiques. Sinon, le nom de la correspondance est recherch� dans le fichier pg_ident.conf dans le m�me r�pertoire que pg_hba.conf. La connexion est accept�e si ce fichier contient une entr�e pour cette correspondance avec le nom de l'utilisateur du syst�me d'exploitation et le nom d'utilisateur PostgreSQL demand�.
Pour les connexions locales, ceci ne marche que sur les machines qui supportent les certificats sockets du domaine Unix (actuellement Linux, FreeBSD, NetBSD, OpenBSD et BSD/OS).
Voir Section 19.2.4 ci-dessous pour les d�tails.
Authentifie en utilisant les Pluggable Authentification Modules (PAM) fournis par le syst�me d'exploitation. Voir Section 19.2.5 pour les d�tails.
La signification de ce champ optionnel d�pend de la m�thode d'authentification choisie et est d�crite dans la section suivante.
Les enregistrements du fichier pg_hba.conf sont examin�s s�quentiellement pour chaque tentative de connexion, l'ordre des enregistrements est significatif. G�n�ralement, les premiers enregistrements auront des param�tres d'interception de connexions plus stricts alors que les enregistrements suivants auront des param�tres plus larges et des m�thodes d'authentification plus fortes. Par exemple, on pourrait souhaiter utiliser l'authentification trust pour les connexions TCP/IP locales mais demander un mot de passe pour les connexion TCP/IP distantes. Dans ce cas, un enregistrement sp�cifiant une authentification trust pour les connexions issues de 127.0.0.1 appara�trait avant un enregistrement sp�cifiant une authentifications par mot de passe pour une plage plus �tendue d'adresses IP client autoris�es.
Important�: N'interdisez pas au super-utilisateur d'acc�der � la base de donn�es template1. Plusieurs commandes de gestion ont besoin d'acc�der � template1.
Le fichier pg_hba.conf est lu au d�marrage et quand le processus serveur principal (postmaster) re�oit un signal SIGHUP. Si vous �ditez le fichier sur un syst�me actif, vous aurez � signaler au postmaster (en utilisant pg_ctl reload ou kill -HUP) de relire le fichier.
Un exemple de fichier pg_hba.conf est d�crit ci-dessous Exemple 19-1. Voir la section suivante pour les d�tails des m�thodes d'authentification.
Exemple 19-1. Un fichier pg_hba.conf d'exemple
# Permet � n'importe quel utilisateur du syst�me local de se connecter � la base # de donn�es sous n'importe quel nom d'utilisateur en utilisant les sockets du # domaine Unix. (par d�faut pour les connexions locales) # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD local all all trust # Identique � ci-dessus mais utilise les connexions TCP/IP locales loopback. # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 127.0.0.1 255.255.255.255 trust # Identique � la derni�re ligne mais en utilisant un masque CDIR. # # TYPE DATABASE USER IP-ADDRESS/CIDR-mask METHOD host all all 127.0.0.1/32 trust # Permet � n'importe que utilisateur de n'importe quel h�te avec l'adresse IP # 192.168.93.x de se connecter � la base de donn�es "template1" sous le m�me nom # d'utilisateur que l'identification le signale � la connexion (g�n�ralement le # nom utilisateur Unix). # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host template1 all 192.168.93.0 255.255.255.0 ident sameuser # Identique � la ligne pr�c�dente mais en utilisant un masque CDIR. # # TYPE DATABASE USER IP-ADDRESS/CIDR-mask METHOD host template1 all 192.168.93.0/24 ident sameuser # Permet � un utilisateur de l'h�te 192.168.12.10 de se connecter � la base de # donn�es "template1" si le mot de passe de l'utilisateur est fourni sans # erreur. # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host template1 all 192.168.12.10 255.255.255.255 md5 # En l'absence de lignes "host" ant�rieures, ces deux lignes rejetteront toutes # les connexions en provenance de 192.168.54.1 (puisque cette entr�e d�clenchera # en premier), mais autorisera les connexions Kerberos V de n'importe o� # ailleurs sur l'Internet. Le masque z�ro signifie qu'aucun bit sur l'ip de # l'h�te n'est consid�r�, de sorte � correspondre � tous les h�tes. # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 192.168.54.1 255.255.255.255 reject host all all 0.0.0.0 0.0.0.0 krb5 # Permet � tous les utilisateurs de se connecter depuis 192.168.x.x � n'importe # quelle base de donn�es si ils passent la verification d'identification. Si, # par exemple, l'identification indique que l'utilisateur est "bryanh" et qu'il # demande � se connecter en tant qu'utilisateur PostgreSQL "guest1", la # connexion n'est permise que s'il existe une entr�e dans pg_ident.conf pour la # correspondance "omicron" disant que "bryanh" est autoris� � se connecter en # tant que "guest1". # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 192.168.0.0 255.255.0.0 ident omicron # Si ce sont les trois seules lignes traitant les connexions locales, elles # autoriseront les utilisateurs locaux � se connecter uniquement � leur propre # base de donn�es (bases de donn�es ayant le m�me nom que leur nom # d'utilisateur) exception faite pour les administrateurs et les membres du # groupe "support" qui peuvent se connecter � toutes les bases de donn�es. Le # fichier $PGDATA/admins contient une liste de noms d'utilisateurs. Un mot de # passe est requis dans tous les cas. # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD local sameuser all md5 local all @admins md5 local all +support md5 # Les deux derni�res lignes ci-dessus peuvent �tre combin�es en une seule ligne: local all @admins,+support md5 # La colonne database peut aussi utiliser des listes et des noms de fichiers # mais pas de groupes: local db1,db2,@demodbs all md5
Pr�c�dent | Sommaire | Suivant |
Destruction d'une base de donn�es | Niveau sup�rieur | M�thodes d'authentification |