Vous n'êtes pas identifié(e).

#1 11/01/2017 09:28:54

Jiff
Membre

Plein d'utilisateurs, mais un SU qui se connecte

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 hmm

Dernière modification par Jiff (11/01/2017 09:50:01)

Hors ligne

#2 21/01/2017 23:27:16

Jiff
Membre

Re : Plein d'utilisateurs, mais un SU qui se connecte

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

Pied de page des forums