pg_hba.conf (part2)

(Dans la première partie on a vu comment configurer l'accès local à un serveur Postgresql)

Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
    psql -h host  database  username

On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3

> psql -h 192.168.0.3  postgres  postgres
psql: n'a pas pu se connecter au serveur : Connection refused
      Le serveur est-il actif sur l'hôte « 192.168.0.3 » 
      et accepte-t-il les connexions TCP/IP sur le port 5432 ?

Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
    listen_addresses = '*'

puis redémarrer le serveur Postgresql
    systemctl restart postgresql

On ré-essaye :
    psql  -h 192.168.0.3  postgres  postgres
    psql: FATAL:  no pg_hba.conf entry for host "192.168.0.59",
    user "postgres", database "postgres", SSL off

Maintenant il faut autoriser les connections sur la base du triplet : (data-base, user, ip-client)

Pour faire simple on va ajouter cette ligne à pg_hba.conf
    host   all   all   all   md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !

En utilisant cette ligne
    host   all   all   samenet   md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.

En utilisant cette ligne
    host   sameuser   all   samenet   md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)

En utilisant ces deux lignes en même temps
    host   webapp    webapp  w.x.y.z/32  md5
    host   sameuser  all     a.b.c.0/24  md5
Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup  jean/jean


Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf

RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.

Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html




 

pg_hba.conf (part1)

Dans cette première partie on va voir comment sécuriser Postgresql  juste après son installation.


1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.

> psql
psql: FATAL:  role "bidule" does not exist

En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.

En fait, pour l'utilisateur 'bidule'
    > psql
est équivalant de
    > psql bidule bidule

Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.


2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :

> psql postgres postgres
psql (9.2.7)
Type "help" for help.

postgres=# _

Effectivement, on a bien le prompt du serveur Posgresql.


3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf

    local   all   all  trust

Elle signifie qu'en 'local', toutes  les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.

Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.

Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.


4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres'  (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local   all   all  md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'

En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...

4.1) Donc on se connecte à Posgresql avec:

    > psql postgres postgres

puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :

    ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
    \q


4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host    all  all  127.0.0.1/32   trust
# host    all  all  ::1/128        trust
On sauve, puis on redémarre le serveur Postgresql :

    systemctl restart postgresql


4.3) Maintenant si on utilise la commande  psql on doit taper le mot de passe

    > psql postgres postgres
    Password for user postgres: xxxxxxxxxxxx
    psql (9.2.7)
    Type "help" for help.
   
    postgres=# _

Ouf !

Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.

Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf

Passons à l’accès via le réseaux ...

Postgresql 9 + Centos 7

Un rapide mémo sur l'installation de Postgresql 9.x sur centos7 avec un PGDATA personnalisé.

1: Installer postgresql

yum install postgresql postgresql-server

2: Créer le home directory de postgresql

mkdir /home/postgres
chown postgres:postgres /home/postgres

3: Initialiser le repertoire où postgresql va stocker ses bases de données et autres meta-data

su postgres
cd
initdb /home/postgres/data
exit

4: Configuration systemd

Ce qui suit a pour but de ne pas modifier la version d'origine de  /usr/lib/systemd/system/postgresql.service

La solution proposé par postgresql est d'utiliser .include mais il faut savoir que cette méthode  est obsolète (https://lists.fedoraproject.org/pipermail/devel/2014-July/200804.html)

Créer le fichier  /etc/systemd/system/postgresql.service
avec ces 3 lignes (respectez la case)

.include /usr/lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/home/postgres/data

Si nécessaire ajouter la ligne suivante pour aussi changer le port

Environment=PGPORT=2345

5: Démarrer le serveur postgresql à la main

systemctl daemon-reload                (important)

systemctl start postgresql

verifier les log

systemctl status postgresql

6: Si tout va bien activer le démarrage automatique

systemctl enable postgresql 

Reste à configurer /home/postgres/pg_hba.conf
Voir ces 3 posts:

• pg_hba (part1)  accès local avec/sans mot de passe
• pg_hba (part2)  accès via le réseau
• pg_hba + SSL   cryptage

7: Installer les extensions

yum install postgresql-contrib

Toutes les extensions vont dans /usr/share/pgsql/extension
Pour installer une extension (par exemple adminpack) dans une base il faut se se connecter à cette base avec le user postgres et taper

CREATE EXTENSION adminpack;



8: Installer les .h


yum install postgresql-devel

Necessaire si on veut compiler un driver pour perl php ruby etc...
Par exemple quand un programme d’installation a besoin de libpq-fe.h

DBD-pg ActiveState & MSVC2013

Dernière étape de notre périple : compiler le driver DBI pour postgresql 9.3 sous Windows.

On suppose que sont déjà installés ces 3 logiciels :
-    Visual C/C++ (MSVC 2013)   (la version gratuite dite 'express' est suffisante)
-    Perl d’ActiveState 5.16           (vous devez pouvoir l’exécuter depuis la ligne de commande)
-    PostgreSQL 9.3.x                     (vous devez pouvoir vous y connecter en local)

(les versions sont données à titre indicatif. Il peut y avoir de variations)

1) Préparer le Makefile de DBD-pg

Télécharger ici : http://search.cpan.org/~turnstep/DBD-Pg/
puis décompacter les sources de DBD-pg 3.x

Ouvrir une ligne de commande (cmd.exe) à la racine des sources de DBD-pg
et taper ces 3 commandes:(à adapter suivant les versions de Postgres et de VC)

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"
"C:\Program Files (x86)\PostgreSQL\9.3\pg_env.bat"
perl Makefile.PL

Si les environnements VC, Perl et PostgreSQL sont corrects tout se passe bien.

2) Compilation de DBD-pg

Taper la commande

nmake  

Si vous avez l’erreur  'C:\Program' is not recognized as an internal or external command, operable program or batch file. Voir dans l’article sur la compilation de mod_perl comment le corriger.

3) Tests de DBD-pg

Avant de lancer les tests il faut créer un rôle de connexion  ‘test’ et une base de donnée ‘test’ appartenant au rôle ‘test’
NB: Si vous utilisez Postgresql 9.0 ou + récent, il faut que ce rôle ai les droits de superviseur sur la base ‘test’.

Adaptez si nécessaire et taper ces 3 commandes :

Set DBI_DSN=dbi:Pg:dbname=test
Set DBI_USER=test
Set DBI_PASS=xxxx

Puis lancer les tests :

nmake test

* Si vous avez des caractères ou des texte bizarres  et/ou si vous avez des erreurs du type
Failed test 'Dollar quotes with invalid characters are not parsed as identifier
C’est parce que les messages d’erreurs de postgresql ne sont pas en Anglais !
Le test attend « syntax error » et il trouve « erreur de syntaxe », et ça lui va pas...

Pour passer les messages du serveur postgresql en anglais :
Éditer le fichier postgresql.conf (il est dans le répertoire data) et remplacer 
  lc_messages = 'French_France.1252'
par 
  lc_messages = 'en_EN.utf8'

Truc : Pour passer la console Windows en UTF8 taper la commande
chcp 65001

Pour que le changement dans postgresql.conf prenne effet arrêter/redémarrer le serveur postgresql depuis une console en admin :

sc stop postgresql-9.3
sc start postgresql-9.3

* Que faire si vous avez l’erreur suivante ?
    error: permission denied for relation pg_largeobject

Depuis PostgreSQL 9.0 il faut être superuser de la base pour accéder à pg_largeobject.
L’erreur est donc normale si le user ‘test’ n’est pas superuser ET si c'est au moins posgres 9. Vous pouvez lui donner ce droit, refaire les tests.

* Si tout se passe bien ça finit par

...
t/99cleanup.t ....... 1/1 Removing test database directory
t/99cleanup.t ....... ok
All tests successful.
Files=16, Tests=2089, 21 wallclock secs
Result: PASS

 

4) Installation de DBD-pg

Dernière commande:

nmake install

Il s’agit juste de copier des fichiers donc pas de problèmes attendus.


Partez pas !
Il reste à supprimer la base de donnée et le rôle utilisé pour les tests.