Vous n'êtes pas identifié(e).
Bonjour,
j'ai crée un mapping pour un utilisateur local lambda, j'obtiens un "ERREUR: droit refusé pour la relation"
le même mapping pour un utilisateur local ayant des droits admin : nickel
Je serai tenté de déduire que l'utilisateur local doit avoir des droits particuliers; mais je n'en trouve pas mention ici :
https://docs.postgresql.fr/10/postgres-fdw.html
Dernière modification par pg_linux (11/02/2018 19:44:05)
Hors ligne
Quelle est la requête sql qui provoque cette erreur?
Qui est le possesseur de la table (c.a.d qui a exécuté le CREATE FOREIGN TABLE) ?
Est-ce le même utilisateur que celui qui lance cette requête ou un autre?
Un utilisateur lambda n'a pas le droit par défaut de sélectionner une table qui ne lui appartient pas, qu'elle soit locale ou distante.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
La requête qui provoque l'erreur est de type SELECT ...
Le "create foreign table" a été fait part l'utilisateur postgres
l'utilisateur qui lance la requête est un utilisateur lambda (ça marche pas) et un utilisateur admin (pas postgres, un autre)
Le "CREATE USER MAPPING FOR local_user" ne correspond-t-il pas à donner ce droit à local_user ?
Hors ligne
Pour moi le CREATE USER MAPPING ne donne pas de droit implicite sur les tables distantes créées plus tard. Les droits sur les tables distantes sont gérées exactement comme pour tables locales: le possesseur a tous les droits et les autres doivent acquérir via un GRANT, plus ou moins direct.
Sur la question de l'utilisateur admin, dans postgres, je comprends ça comme admin=SUPERUSER. postgres n'est pas un utilisateur spécial en-dehors d'être SUPERUSER et tout utilisateur SUPERUSER peut faire la même chose que lui. Pour un SUPERUSER, grosso-modo tous les tests de droits d'accès sont court-circuités. Il pourra toujours faire n'importe quoi sur n'importe quelle table.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Ok en effet, résolu avec un :
grant select on foreign_table to local_user;
Hors ligne