Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je travaille sur des bases supérieures à 8.0 sous Red-Hat et Cent-OS.
L'installation est faite avec un Utillisateur Système "postgres"
Le fichier postgresql.conf contient le paramètre : listen_addresses = '*'
Le fichier pg_hba.conf est configuré :
local all all trust
host all all IP MASK trust
host all all ::1/128 trust
Est-ce que tout le contenu de la BD appartient à ce "Super-Utilisateur" PostgreSQL de même nom que l'Utilisateur Système ?
Ce "Super-Utilisateur" PostgreSQL a t'il un mot de passe ? Est-ce le même que celui de l'Utilisateur Système ?
Pour mettre en place la sécurité, nous souhaitons :
- changer le mot de passe du "Super-Utilisateur" que tout le monde connait à présent.
Est-ce possible ? et quel impact ?
- créer de nouveaux utilisateurs PostgreSQL en adéquation avec nos applicatifs.
Faut-il utiliser les commandes CREATE ROLE ?
Y-a-t'il des GRANT à faire pour que ces utilisateurs puissent faire des insert/update/delete ?
- restreindre l'accés à la base de données à certains postes clients uniquement.
Est-ce bien au niveau du pg_hba.conf qu'il faut donner la liste des postes, avec nom de base de données et password ?
- restreindre les actions dans la base de données (accés à certaines tables, delete interdit sur certaines tables, ...).
Est-ce que cela se gère également avec les GRANT ?
Globalement est-ce une bonne première approche pour gérer la sécurité ?
Je sais cela fait beaucoup de questions, mais nous n'avions, jusqu'à aujourd'hui, aucun besoin de sécurité.
J'ai déjà pas mal lu de documentation PostgreSQL, si vous voulez bien juste m'aiguiller.
Je vous remercie par avance.
Hors ligne
Les objets (les tables, etc…) appartiennent à la personne qui les a créés, sauf si vous avez altéré le propriétaire de ces objets ultérieurement (alter table … owner …)
À l'heure actuelle vous n'avez aucune sécurité en place, puisque vous avez, comme authentification, 'trust'. Je vous conseille, pour commencer (pour comprendre le pg_hba.conf) de lire le guide de démarrage rapide, qui est en page d'accueil de www.postgresql.fr .
Sinon, évidemment, vous pouvez (une fois que le pg_hba.conf est bon) donner des mots de passe à chaque utilisateur, contrôler les accès à chaque base, créer des utilisateurs (create role effectivement), leur accorder des droits (avec la commande grant, toujours effectivement).
Commencez donc par le guide de démarrage rapide. Sinon, le chapitre sur les droits, dans la documentation, est un de ceux qui sont particulièrement clairs : http://docs.postgresql.fr/9.0/user-manag.html
Évidemment, s'il vous reste des doutes après la lecture de ces quelques pages de docs, n'hésitez pas à poser des questions complémentaires.
Marc.
Hors ligne
Bonjour à tous,
Merci Marc pour la réponse, j'ai suivi votre conseil.
J'ai modifié le password de mon Utilisateur Système postgres.
J'ai modifié mon pg_hba.conf (local all postgres ident sameuser) pour tester les connexions locales. J'ai ensuite fait un "pg_ctl reload". La connexion fonctionne.
J'ai mis le même password à mon Utilisateur PostgreSQL postgres, que mon Utilisateur Système, pour voir le comportement.
Maintenant il me demande le password à la connexion (psql [DBNAME]), malgrès le "ident sameuser".
Comment faire pour qu'il ne me demande pas ce password ? ou quelle est la commande pour l'enlever ?
Merci pour votre aide.
Hors ligne
J'ai trouvé la commande pour enlever le mot de passe :
ALTER ROLE postgres WITH PASSWORD NULL;
Mais il me demande toujours un mot de passe à la connexion et lorsque je ne met rien, j'obtiens le message d'erreur :
psql: fe_sendauth: no password supplied
Au secours.
Hors ligne
Le mot de passe NULL désactive l'authentification par mot de passe. Vous ne pouvez plus vous connecter par mot de passe quand c'est le cas. Si vous voulez vous connecter sans demande de mot de passe, c'est la méthode ident (si vous êtes sous Unix, ce qui est votre cas) ou trust qu'il faut utiliser (je vous déconseille, évidemment, la méthode trust si vous voulez sécuriser les accès).
Je présume que ce que vous cherchez à faire, c'est à donner accès à l'utilisateur système postgres de votre serveur au compte postgres de vos bases, sans demande de mot de passe ?
Si c'est bien ce que vous cherchez à faire, le plus simple, c'est de mettre en premières lignes de votre pg_hba.conf :
local all postgres ident sameuser
host all postgres 127.0.0.1/32 ident sameuser
Ces deux lignes vous permettront de vous connecter sans mot de passe. Uniquement à partir du compte système postgres, et uniquement en local (pour des raisons évidentes de sécurité).
Comme c'est ce que vous avez l'air d'avoir fait (au moins la ligne local, qui correspond à une socket unix, qui est bien le type de socket que vous utilisez puisque vous n'utilisez pas l'option -h de psql), je pense que c'est qu'il y a une erreur de syntaxe dans votre pg_hba.conf. Si c'est le cas, elle devrait être tracée après le reload, dans la log postgres.
Marc.
Hors ligne
Marc,
J'ai modifié le pg_hba.conf avec les 2 lignes que vous avez donné.
Dans les logs, j'ai ceci :
3602 2011-05-09 10:22:01 CEST 46 LOG: received SIGHUP, reloading configuration files
3602 2011-05-09 10:22:01 CEST 47 LOG: authentication option not in name=value format: sameuser
3602 2011-05-09 10:22:01 CEST 48 CONTEXT: line 75 of configuration file "/home/postgres/PG_DATA/pg_hba.conf"
3602 2011-05-09 10:22:01 CEST 49 LOG: authentication option not in name=value format: sameuser
3602 2011-05-09 10:22:01 CEST 50 CONTEXT: line 76 of configuration file "/home/postgres/PG_DATA/pg_hba.conf"
3602 2011-05-09 10:22:01 CEST 51 WARNING: pg_hba.conf not reloaded
Hors ligne
Zut, il n'y a plus besoin de mettre sameuser depuis la 8.4… mettez juste ident, cela va suffire (sameuser est la valeur par défaut, et elle n'est plus acceptée)
Marc.
Hors ligne
Ok, Marc, cela fonctionne.
Si j'ai bien compris, la 2ème ligne est pour les connexions distantes ?
Je dois maintenant définir mes Utilisateurs Applicatifs, leur accorder les droits INSERT/UPDATE/DELETE. Puis mettre les adresses IP des postes applicatifs qui auront droit d'accés.
Merci encore pour votre aide.
Hors ligne
La seconde ligne est pour les connexions locales, mais en TCP (127.0.0.1 est l'adresse de loopback). Celles qu'on a quand on fait «psql -h localhost»
Il ne faut surtout pas utiliser ident avec des sessions TCP provenant d'autres machines. Cela reviendrait à faire confiance au système distant pour l'authentification des utilisateurs.
Marc.
Hors ligne
Marc,
J'ai ajouté la ligne suivante pour me permettre, depuis mon PC (IP pour exemple 199.199.199.199), de travailler avec PgAdmin :
host all postgres 199.199.199.199 255.255.255.0 trust
J'ai également une application JAVA qui tourne en local sur le serveur et qui utilise un fichier de configuration où sont précisés :
<URL>jdbc:postgresql://localhost:5432/test</URL>
<UID>postgres</UID>
<PWD>pwd</PWD>
Ce dernier n'arrive plus à se connecter ?? n'utilise t'il pas la ligne ?
host all postgres 127.0.0.1/32 ident
Hors ligne
199.199.199.199 255.255.255.0, ça veut dire tout le réseau 199.199.199 (à cause du netmask), je présume que c'est une erreur ?
Pour ce qui est de l'appli java, elle utilise la ligne, normalement. Il serait intéressant d'aller voir le message d'erreur dans la log de postgres quand elle essaye de se connecter (on a la raison du rejet).
Marc.
Hors ligne
J'ai mis cette "pseudo" adresse pour l'exemple (j'ai effectivement mis l'adresse IP de mon PC avec le masque correspondant).
Dans le fichier de LOG, j'ai les messages
127.0.0.1 17994 2011-05-09 15:30:23 CEST authentication 1 LOG: could not connect to Ident server at address "127.0.0.1", port 113: Connexion refusée
127.0.0.1 17994 2011-05-09 15:30:23 CEST authentication 2 FATAL: Ident authentication failed for user "postgres"
Hors ligne
Ah, oui, ok. Faut effectivement avoir un serveur ident installé pour ça (pour ident sur une adresse IP). Soit vous l'installez, soit vous mettez un mot de passe et vous passez l'authentification 127.0.0.1 en md5. L'idéal serait aussi, évidemment, que l'application java ne se connecte pas en tant que postgres, pour des raisons de sécurité.
Marc.
Hors ligne
D'accord Marc, j'ai mis md5.
Merci pour votre aide.
Hors ligne
Pages : 1
