Comprendre les droits

Vinorcola · 22/01/2014 16:11:11

Bonjour à tous,
.
J'ai décidément beaucoup de mal à comprendre comment les droits d'utilisateur fonctionnent dans Postgres.
.
Nous avons plusieurs utilisateurs qui appartiennent à un même groupe. Et je voudrais que chacun des utilisateurs aient l'intégralité des droits sur tous se que créaient les autres utilisateurs de ce même groupe. J'ai donc modifier les droits par défaut du schéma de la base de données :
.
ALTER DEFAULT PRIVILEGES IN SCHEMA our_schema GRANT ALL ON TABLES TO our_group;
ALTER DEFAULT PRIVILEGES IN SCHEMA our_schema GRANT ALL ON SEQUENCES TO our_group;
ALTER DEFAULT PRIVILEGES IN SCHEMA our_schema GRANT ALL ON FUNCTIONS TO our_group;
.
Mais cela n'y fais rien. Par defaut, les droits ne sont pas données aux autres utilisateurs du groupe de lire ou modifier les données. Il faut explicitement changer le owner de la table par our_group pour que tout le monde y ai accès. Mais même une fois fait, il est impossible de créer des index. Psql répond que seul le propriétaire peut...
.
Je voudrais donc une solution pour que tout le monde puisse faire n'importe quoi dans ce schéma. Pour le moment, la seule solution trouver est que tout le monde ce connecte avec l'utilisateur postgres.
.
Merci d'avance pour votre aide.

Dernière modification par Vinorcola (22/01/2014 16:11:50)

SQLpro · 22/01/2014 18:21:47

Commençons par la sémantique... Il faut vous débarrasser du mot DROIT qui n'a pas sa place dans les SGBDR relationnel. La notion de "droit" est purement système.. Droit de lire, d'écrire... Or dans un SGBDR le seul qui a le droit de lire ou d'écrire est le moteur relationnel ! Tout ce que les utilisateurs peuvent faire c'est envoyer des requête SQL (qui sont des demandes) en espérant qu'elles produisent leur effet sur les objets manipulés.

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 +

Dernière modification par SQLpro (22/01/2014 18:24:36)

gleu · 22/01/2014 23:11:27

Il faut considérer deux choses : les droits sur l'accès aux données (en gros lire et écrire), et les droits de modifications des propriétés des objets (l'ajout d'une colonne, d'un index ou le renommage d'un objet, par exemple).

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.

Vinorcola · 23/01/2014 12:05:21

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.

En tout cas, vos lecture m'ont apporter beaucoup de chose ^^.

Merci.

SQLpro · 23/01/2014 12:16:52

Vinorcola a écrit :

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 +

arthurr · 23/01/2014 12:28:14

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 !

Raté : http://docs.postgresql.fr/9.3/sql-creat … igger.html

Vinorcola · 23/01/2014 16:01:19

Ok, je vais étudié du côté des triggers. Merci d'avance.

SQLpro · 23/01/2014 16:25:32

arthurr a écrit :

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 !
Raté : http://docs.postgresql.fr/9.3/sql-creat … igger.html

ha ben je suis en retard d'une version !!!

A +

#1 22/01/2014 16:11:11

Comprendre les droits

#2 22/01/2014 18:21:47

Re : Comprendre les droits

#3 22/01/2014 23:11:27

Re : Comprendre les droits

#4 23/01/2014 12:05:21

Re : Comprendre les droits

#5 23/01/2014 12:16:52

Re : Comprendre les droits

#6 23/01/2014 12:28:14

Re : Comprendre les droits

#7 23/01/2014 16:01:19

Re : Comprendre les droits

#8 23/01/2014 16:25:32

Re : Comprendre les droits

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux