Vous n'êtes pas identifié(e).
Bonjour,
Je ne suis pas sur de poster ma question dans la bonne section, désolé par avance si je me suis trompé.
Je rencontre une difficulté dans l'utilisation de postgresq_fdw .
Voici les éléments du problème:
Je dispose de deux bases de données.
La base 1 contient des observations naturalistes, la base 2 des zones d'étude.
Mon serveur autorise les connexions sans mot de passe pour tous les utilisateurs locaux à n'importe quelle base (voir extrait de pg_hba.conf + bas).
Je voudrais "avoir accès" (SELECT uniquement) à la table zone_etude de ma base 2.
J'ai mis en place une connexion via postgres_fdw pour avoir accès aux données.
Attribué les droits nécessaire et mappé les utilisateurs.
Voici ce que ça donne:
--création connexion
CREATE SERVER referentiel FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'localhost', dbname 'base2', port '5432');
--mapping users
CREATE USER MAPPING FOR superuser
SERVER srv_base2 OPTIONS (USER 'user');
CREATE USER MAPPING FOR bidule
SERVER srv_base2 OPTIONS (USER 'user');
--création schéma et import données
CREATE SCHEMA fdw_base2 ;
GRANT USAGE ON SCHEMA fdw_base2 TO base1_groupe_concerne;
IMPORT FOREIGN SCHEMA schema_base2 LIMIT TO (zone_etude)
FROM SERVER srv_base2
INTO fdw_base2 ;
GRANT SELECT ON TABLE fdw_base2.zone_etude TO base1_groupe_concerne;La connexion fonctionne comme je le désire en tant que superuser:
select count(*) from fdw_base2.zone_etude;
count
-------
93
(1 ligne)Par contre en utilisateur simple:
select count(*) from fdw_base2.zone_etude;
ERREUR: password is required
DÉTAIL : Non-superusers must provide a password in the user mapping.Après quelques recherches sur le net je suis tombé sur cette information dans la documentation officielle postgresql ( https://docs.postgresql.fr/9.6/postgres-fdw.html ):
F.33.1. Options FDW de postgres_fdw
F.33.1.1. Options de connexionsUn serveur distant utilisant le wrapper de données distantes postgres_fdw peut avoir les mêmes options que celles acceptées par libpq dans les chaînes de connexion comme décrit dans Section 32.1.2, « Mots clés de la chaîne de connexion ». Cependant, ces options ne sont pas autorisées :
user et password (spécifiez-les au niveau de la correspondance d'utilisateur)
client_encoding (ceci est configuré automatiquement à partir de l'encodage du serveur local)
fallback_application_name (toujours configuré à postgres_fdw)
Seuls les superutilisateurs peuvent se connecter à un serveur distant sans authentification par mot de passe. Donc spécifiez toujours l'option password pour les correspondances d'utilisateur appartenant aux utilisateurs simples.
Pour information je vous colle la ligne de mon pg_hba.conf qui permet la connexion de n'importe user à n'importe quelle base sans mdp.
# IPv4 local connections:
host all all 127.0.0.1/32 trustSavez-vous contourner cette limitation?
Merci d'avance.
Hors ligne
Essayez de mettre un mot de passe bidon… Il sera de toutes façons ignoré au moment de la connexion si en face c'est du trust.
Vous êtes dans une configuration peu «naturelle», habituellement on met des mots de passe (ou une autre méthode d'authentification sécurisée). J'imagine que le code du foreign data wrapper regarde si il y a un password= dans la chaîne.
Marc.
Hors ligne
Pardon, j'ai oublié de préciser que j'avais déjà testé cette manip.
Dans ce cas l'erreur sur le count est la suivante:
select count(*) from fdw_base2.zone_etude;
ERREUR: password is required
DÉTAIL : Non-superuser cannot connect if the server does not request a password.
ASTUCE : Target server's authentication method must be changed.Merci pour la proposition en tous cas! 
Hors ligne
Ok, je suis allé regarder un peu plus sérieusement. Si vous utilisez un utilisateur non super-user, le FDW vérifie que l'authentification au serveur distant a nécessité un mot de passe. Voila le bout de code associé:
if (!superuser() && !PQconnectionUsedPassword(conn))
ereport(ERROR,
(errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
errmsg("password is required"),
errdetail("Non-superuser cannot connect if the server does not request a password."),
errhint("Target server's authentication method must be changed.")));Il faut donc qu'un mot de passe ait été fourni pour établir la connexion. Il faut donc que le serveur en face demande un mot de passe. Pour que ça marche vous avez donc besoin:
* D'avoir une authentification par mot de passe, au moins pour l'utilisateur utilisé par le FDW (md5 dans le pg_hba.conf)
* Et que ce mot de passe soit fourni dans le user mapping (puisque vous voulez pouvoir utiliser la foreign table sans fournir de mot de passe).
Le but, j'imagine, c'est d'éviter les erreurs de configuration manifestes, où n'importe qui peut faire n'importe quoi à partir du moment où il y a un foreign server.
Marc.
Hors ligne
Merci pour ces investigations que j'aurais été bien incapable de mener.
Question suivante du coup, pour forcer l'usage d'un mot de passe pour l'utilisateur appelé par le FDW.
J'utilise la version 9.6 de postgresql sous debian.
Je pensais forcer l'usage en ajout la ligne ci-dessous (après la ligne trust car il me semble me souvenir que le fichier pg_hba est lu de haut en bas).
Mais rien n'y fait l'authentification via "trust" est toujours prioritaire.
host all all 127.0.0.1/32 trust
host base2 user_fdw 127.0.0.1/32 md5Auriez-vous une idée de ce que j'ai raté?
Hors ligne
Les deux entrées sont à l'envers: le pg_hba est lu ligne par ligne jusqu'à la première qui correspond à la demande de connexion en cours.
Marc.
Hors ligne
J'avais effectivement essayé, mais l'erreur persiste.
Je suis perplexe, voici les lignes décommentées de mon pg_hba.conf.
J'ai masqué certaines informations (pour des raisons de sécurité) avec des *.
local all postgres peer
local all all peer
# IPv4 local connections:
host base2 user_fdw 127.0.0.1/32 md5
host all all 127.0.0.1/32 trust
host e****e a*****p 213.152.*.*/32 md5
host e****e g********e 37.187.*.*/32 md5
# IPv6 local connections:
host all all ::1/128 trustJ'ai bien redémarré mon serveur postgresql après modifications du fichier.
Je ne comprends pas ce que j'ai raté, mon fichier ressemble pourtant à l'exemple fournit par la doc officielle:
# Require SCRAM authentication for most users, but make an exception
# for user 'mike', who uses an older client that doesn't support SCRAM
# authentication.
#
# TYPE DATABASE USER ADDRESS METHOD
host all mike .example.com md5
host all all .example.com scram-sha-256Un dernier coup de pouce?!
EDIT: la connexion avec mot de passe fonctionne si je la force:
psql -h localhost -p 5432 base2 -U user_fdw -WDans le cas contraire (sans le -W), le mot de passe n'est pas demandé.
Je ne comprends pas ce qui m$§*e.
Dernière modification par Mathieu Denat (27/07/2017 12:33:25)
Hors ligne
Plusieurs trucs qui me viennent à l'esprit:
* Vous n'avez pas fait de reload (j'imagine que ce n'est pas ça mais autant demander quand même )
* localhost ne serait pas résolu en ipv6 tout simplement ?
Sinon, faites attention, l'exemple que vous donnez doit venir de la version de dev. scram, ça ne sera qu'en v10.
Marc.
Hors ligne
Bingo!
C'était une histoire d'ipV6!
N'utilisant ipv6, j'ai purement et simplement déactivé, pour ceux que ça intéresse j'ai suivi le tuto suivant (sous debian 9):
https://www.memoinfo.fr/tutoriels-linux … ur-debian/
Mille mercis, tout roule!
Hors ligne