Vous n'êtes pas identifié(e).
Pages : 1
Salut forumers (bonne année et tout plein de choses, surtout la santé),
.
NB: Les utilisateurs n'ont pas d'accès direct aux données ni même aux vues, seulement à certaines fonctions et encore, pas directement; seul le serveur (middleware) a accès à ces fonctions - Les requêtes des utilisateurs sont des RPC sur le serveur qui connaît tous les droits d'accès accordés aux utilisateurs ainsi que leur nom et mot de passe (hash ≠ md5).
.
Je me demande si la bonne solution pour éviter d'avoir à fermer les connections rapidement (à cause du nombre d'utilisateurs >> nombre de connexions) ne serait pas de passer par des connexions permanentes ouverte par un SU ?
.
Donc, disons, par exemple:
100 connections ouvertes par pgbouncer au nom d'un SU,
50 connections en réserve au cas où,
2 connexions réservées aux DBA et admin de la DB. Ensuite, quand le serveur reçoit une requête d'un client.
.
Dans cet exemple, le client est déjà connecté (login/pw ≠ de Pg).
* Client requête,
* Serveur vérifie si le client a le droit d'appeler la fonction, (on va dire que vi, sinon le client se fait jeter et logger)
* Serveur construit la requête PG (SQL) dans un bloc de transaction (niveau SERIALIZED),
* Serveur envoie: SET SESSION AUTHORIZATION <role> à pgbouncer,
* Serveur envoie le bloc de transaction à pgbouncer et papote avec le DBA en attendant la réponse,
* Serveur reçoit la réponse,
* Serveur la transmet au client,
* Serveur envoi RESET SESSION AUTHORIZATION à pgbouncer.
.
Q1: Est-ce une bonne façon de faire, et si non, pourquoi ?
.
Q2: Je vois le distinguo entre SET SESSION AUTHORIZATION <role> et SET ROLE <role> (SESSION_USER restant au role du SU dans le 2nd cas), mais quelle différence cela pourrait-il faire dans une configuration telle que la mienne si j'utilisai SET ROLE ?
.
Merci d'avance.
.
PS: Le tracking sur HTTP referer & user agent pour pouvoir poster, c'est l'enfer
Dernière modification par Jiff (11/01/2017 09:50:01)
Hors ligne
Bon, comme on n'est jamais si bien servi que par soi-même, je me réponds avec une solution qui évite tout recours à un compte SU (trouvée sur stackoverflow.)
.
Créer le user devant accéder aux données:
CREATE USER machin LOGIN PASSWORD 'trucbiencompliqué';
et lui donner tous les droits voulus sur les views et fonctions de la DB.
.
Créer le user qui va endosser toutes les connexions, puis prendre temporairement l'identité de l'utilisateur devant effectuer une/des opérations sur la DB:
CREATE USER access NOINHERIT LOGIN PASSWORD 'trucencorepluscompliqué';
et lui accorder les droits du user normal (dont il n'héritera pas, puisque qu'il a NOINHERIT):
GRANT machin TO access;
Créer les connexions PgBouncer à la DB avec le user 'access' (qui n'a donc aucun droit en dehors de la connexion - NB: dans mon cas particulier, elles restent ouvertes tant que le serveur est up.)
.
Quand le besoin s'en fait sentir, exécuter la substitution avec:
SET ROLE machin;
puis bricoler tout ce que l'on veut sous le compte 'machin'. Pour revenir à l'état antérieur, faire:
RESET ROLE;
Je n'ai pas trouvé plus simple, ni plus sécurisé.
Hors ligne
Pages : 1