Vous n'êtes pas identifié(e).
Bonjour à tous,
Je suis face à un problème que je ne parviens pas à résoudre :
voici la situation
- j'ai une db : "monprojet"
- j'ai le propriétaire de la db : "monprojet_owner"
- j'ai le groupe admin de la db : "monprojet_admin"
- j'ai un utilisateur final de la db "monprojet" : "u1". "u1" appartient au groupe admin de la db
- j'ai un autre utilisateur : "u2"
Voici ce à quoi je voudrais arriver:
- Je vourdrais que le owner de la db ne puisse pas se connecter à la db ( ca c'est ok).
- je voudrais que l'utilisateur "u2" ne puisse rien faire à part se connecter à la db et et effectuer des select, update delete dans la db ( c'est ok également).
Ce qui me pose problème :
- je voudrais que le groupe admin de la db puisse supprimer des objets sql (schemas, tables, fonctions, types, séquence, etc) , créer des objets sql mais que le propriétaire de ces nouveaux objets sql soit le propriétaire de la db.
L'idéal serait que l'utilisateur "u1" (qui fait partie du groupe admin de la db), lorsqu'il crée un objet sql dans la db :
- Il n'aie pas besoin de faire un set role.
- que tous les objets créés soit au nom du propriétaire de la db.
Est ce possible de suivre ce schéma?
Peut-etre existe-t-il une best practice pour la gestion des utilisateurs?
Merci pour vos réponses.
Hors ligne
Il utilise la clause OWNER et ça marchera parfaitement. Pas de possibilité de le faire en automatique par contre.
Guillaume.
Hors ligne
Merci pour ta réponse Gleu,
Cependant si je comprends bien la clause OWNER implique que celui qui l'utilise soit membre direct/indirect.
Donc, dans mon cas "monprojet_admin" sera membre direct de "monprojet_owner" et "u1" sera membre indirect de "monprojet_owner"
Ce qui implique que si "u1" exécute 'set role monprojet_admin' puis 'set role monprojet_owner', "u1" aura les droits full sur la db.
Hors, je n'ai pas envie que u1 puisse octroyer des droits à d'autres utilisateur.
Hors ligne
Oui, en effet, il doit être un membre du rôle propriétaire.
Votre exemple ne fonctionne pas car u1 n'est pas membre de monprojet_admin et, de ce fait, ne peut pas faire un "SET ROLE monprojet_admin".
Guillaume.
Hors ligne
J'avais indiqué au départ que u1 appartenait à monprojet_admin :
...
- j'ai le groupe admin de la db : "monprojet_admin"
- j'ai un utilisateur final de la db "monprojet" : "u1". "u1" appartient au groupe admin de la db
...
C'est vraiment dommage que PostgreSQL gère cela de cette façon.
En résumé, pour détruire ou créer des objets il faut être membre direct/indirect du propriétaire des objets ou du propriétaire de la db du propriétaire du schéma ou du propriétaire de la db...
Hors ligne
Ce qui implique que si "u1" exécute 'set role monprojet_admin' puis 'set role monprojet_owner', "u1" aura les droits full sur la db.
Avoir tous les droits sur une base (GRANT ALL... ON DATABASE..) ça veut dire:
- CREATE: le droit de créer un schéma
- CONNECT: le droit de se connecter
- TEMPORARY: le droit de créer des tables temporaires
Si u1 est un admin qui peut créer des objets SQL, on suppose qu'il a déjà ces droits.
Concrètement "les droits full sur la db" ça veut dire quoi qu'il n'aurait pas déjà?
Hors, je n'ai pas envie que u1 puisse octroyer des droits à d'autres utilisateur.
Mais la transmission des droits dépend de la clause GRANT OPTION, non?
Et elle n'est pas mentionnée dans le descriptif de la situation.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
par "droits full" sur la db je veux dire avoir tous les droits sur les objets appartenant à cette db ( schemas, tables, fonctions, types, séquences, ...)
Ce que je voudrais arriver à faire c'est :
- avoir un groupe "admin" qui permettrait de créer et supprimer des objets sql (tables, fonctions, types, séquences,operateurs, vues, seulement cela),
- et que le owner des objet créés par le groupe admin soit le propriétaire de la db.
- je ne voudrais pas que le groupe admin aie d'autres droits ( par exemple, ne pas pouvoir donner des droits à des utilisateurs).
Dernière modification par adrien1 (28/09/2017 16:53:45)
Hors ligne
Je ne comprends pas ce qui gêne précisément, mais à toutes fins utiles, voici une piste: un superutilisateur pourrait fournir une fonction en mode SECURITY DEFINER qui ferait le ALTER ... OWNER transférant la possession de l'objet à celui qui possède la base.
Exemple pour les tables, à exécuter par un superutilisateur,donc:
CREATE FUNCTION depossession_table(objname regclass) returns void AS $$
BEGIN
execute format('ALTER TABLE %I OWNER TO owner_de_la_base', objname);
END
$$ SECURITY DEFINER language plpgsql;Ensuite n'importe quel utilisateur créant une table pourrait faire immédiatement:
SELECT depossession_table('nom_de_table');Il est possible de faire une version plus élaborée de cette fonction qui gère les autres types d'objets, ou qui irait chercher le possesseur de la base dynamiquement, etc.
Il est aussi possible d'accorder un GRANT EXECUTE de cette fonction uniquement à certains rôles (dans ce cas commencer par REVOKE EXECUTE... FROM public, par défaut les fonctions étant exécutables par PUBLIC).
Dernière modification par dverite (28/09/2017 19:05:19)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci dverite pour la piste de la fonction depossession().
Ce qui me gène précisément c'est de devoir donner tous les droits et tous les droits admin sur tous les objets sql de la base de données y compris celle-ci à un développeur que l'on intégrerait dans le groupe admin .
Alors que le groupe admin donne juste le droit de créer des objets sql au nom du propriétaire de la base de données.
Hors ligne