SQLpro a écrit :En sus, PG n'offre pas non plus de déclencheurs DDL (se lançant sur un ordre CREATE ALTER ou DROP) contrairement à Oracle ou SQL Server, ce qui aurait permis d'attribuer ces privilèges au moment de la création des objets !
ha ben je suis en retard d'une version !!!
A +
]]>]]>En sus, PG n'offre pas non plus de déclencheurs DDL (se lançant sur un ordre CREATE ALTER ou DROP) contrairement à Oracle ou SQL Server, ce qui aurait permis d'attribuer ces privilèges au moment de la création des objets !
Ok, Merci pour vos réponses.
SQLPro, j'avais déjà créé le groupe est lui avait attribué toutes les permissions au schéma dans lequel nous travaillons. Le soucis principal, c'est que nous créons parfois jusqu'à une vingtaine de tables dans la journée, et je voulais savoir s'il y avait un moyen que tous les utilisateurs agissent au nom du groupe. C'est-à-dire, que lorsque qqn créé une table, cette table appartient au groupe directement plutot qu'à l'utilisateur qui l'a créée.
Hélas non, PstGreSQL n'offre aucune possibilité de ce côté là... contrairement à SQL Server par exemple qui permet de donner des privilèges au niveau des "conteneurs", comme la base (SQL Server est multibase) ou le schéma, donc avec héritage automatique pour les utilisateurs privilègies, ce qui règle une fois pour toute et pour l'avenir, donc la durée de vie de la base, toutes les problématiques d'attribution des privilèges.
En sus, PG n'offre pas non plus de déclencheurs DDL (se lançant sur un ordre CREATE ALTER ou DROP) contrairement à Oracle ou SQL Server, ce qui aurait permis d'attribuer ces privilèges au moment de la création des objets !
A +
]]>SQLPro, j'avais déjà créé le groupe est lui avait attribué toutes les permissions au schéma dans lequel nous travaillons. Le soucis principal, c'est que nous créons parfois jusqu'à une vingtaine de tables dans la journée, et je voulais savoir s'il y avait un moyen que tous les utilisateurs agissent au nom du groupe. C'est-à-dire, que lorsque qqn créé une table, cette table appartient au groupe directement plutot qu'à l'utilisateur qui l'a créée.
En tout cas, vos lecture m'ont apporter beaucoup de chose ^^.
Merci.
]]>Pour le premier, il faut utiliser la commande "ALTER DEFAULT PRIVILEGES IN SCHEMA our_schema GRANT ALL ON TABLES TO our_group;" pour donner les droits sur tous les objets qui seront créés par la suite. Pour les objets déjà existants, il faut utiliser GRANT. Attention qu'on ne parle là que des tables. Il faudra faire la même chose pour les autres types d'objets (pas possible pour tous en ce qui concerne le ALTER DEFAULT PRIVILEGES).
Pour le second, les objets doivent avoir comme propriétaire un groupe et chaque utilisateur qui doit pouvoir modifier les propriétés des objets devra être membre de ce groupe.
Tout ceci étant dit, je ne pense pas que vous puissiez aller jusqu'au bout de votre démarche. Pour ne parler que du ALTER DEFAULT PRIVILEGES, ça ne concerne que quelques objets (tables, vues, séquences, fonctions, types). Pas les schémas, pas les Large Objects, pas les tablespaces, etc. Autrement dit, vous devriez réfléchir à votre besoin réel.
]]>Donc un PRIVILÈGE est la permission d'utiliser une COMMANDE SQL particulière sur un OBJET précis (vue, table, routines...).
Dans une base de données on est confronté à un problème d’œuf et de poule... Pour créer une base il faut un utilisateur SQL qui sera le propriétaire des objets et aura le droit de vie ou de mort et sur ces objets et possède tous les privilèges dessus implicitement. Cet utilisateur ne pourra en aucun cas être supprimé, sinon vous ne pourriez plus, ni modifier, ni supprimer les objets existants, ni même (et bien entendu) transmettre les privilèges sur ces objets.
Ensuite, sachez que la délivrance des privilèges est chainée. Ainsi le propriétaire peut donner tous les privilèges qu'il souhaite, et s'ils les donnent avec la possibilité de rétrocession (WITH GRANT OPTION), alors celui qui a acquis les privilèges peut à son tour les transmettre. Ainsi USER_A donne par GRANT des privilèges à USER_B et si WITH GRANT OPTION, alors USER_B peut faire un GRANT à USER_C des privilèges acquis...
De plus les privilèges sont cumulatifs. C'est à dire qu'un privilège donné 3 fois par 3 utilisateurs nécessite 3 REVOKE pour que l'utilisateur final n'ait plus la possibilité d'agir.
Exemple, soit USER_A, USER_B et USER_C. Si USER_A et USER_B possèdent tous les privilèges sur tous les objets et que les commandes suivantes sont passées :
USER_A lance la commande : GRANT SELECT ON Table1 TO USER_C;
USER_B lance la commande : GRANT SELECT ON Table1 TO USER_C;
alors si USER_A récuse la commande transmise par :
USER_A lance la commande : REVOKE SELECT ON Table1 TO USER_C;
alors USER_C peut toujours faire un SELECT sur la Table1, parce qu'il a acquis de USER_B !
Pour savoir ou vous en êtes des privilèges, il faut lire les métadonnées avec les vues : INFORMATION_SCHEMA.TABLES_PRIVILEGES et INFORMATION_SCHEMA.COLUMN_PRIVILEGES.
Pour que vos utilisateurs puissent faire tout ce que vous voulez, il faut explicitement donner les privilèges adéquats sur chaque objet à chacun des utrilisateurs (si n objet et m utilisateurs, il faudra n x m GRANT !).
IMPORTANT : le GRANT ALL est supprimé dans la norme SQL ce qui signifie qu'un jour il risque de disparaître des commandes PG...
Pas de panique... le plus simple est de passer par un rôle.
1) création d'un rôle :
CREATE ROLE ROL_FAITOUT;
2) attribuer des privilèges à ce rôle :
GRANT INSERT, UPDATE, DELETE, SELECT ON TABLE_1 TO ROL_FAITOUT;
...
3) donner à vos utilisateurs, le rôle ROL_FAITOUT :
GRANT ROL_FAITOUT TO USR_1;
Vos utilisateurs peuvent maintenant faire toute ce que le rôle ROL_FAITOUT leur permet de faire.
Il est important au final de dissocier les rôles permettant des ALTER / CREATE / DROP (propriétaires des objets) et les rôles de production qui permet d'utiliser les objets de la base.
À NOTER : tout ceci fait partie de la norme SQL et est expliqué dans mon livre : "SQL, 4e édition, Colection Synthex, Pearson Educ.
Mon site web en donne un extrait : La gestion des privilèges La notion de rôle ayant été rajoutée avec la version 1999 de la norme SQL.
A +
]]>