web-dev-qa-db-fra.com

Accorder tout sur un schéma spécifique de la base de données à un rôle de groupe dans PostgreSQL

En utilisant PostgreSQL 9.0, j’ai un rôle de groupe appelé "personnel" et souhaite accorder tous (ou certains) privilèges à ce rôle sur les tables d’un schéma particulier. Aucun des travaux suivants

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Les membres de "staff" sont toujours incapables de sélectionner ou de mettre à jour les tables individuelles du schéma "foo" ou (dans le cas de la deuxième commande) d'une table de la base de données sauf si J'accorde tous sur cette table spécifique.

Que puis-je faire pour rendre la vie de mes utilisateurs et de celle de mes utilisateurs plus facile?

Mise à jour: Je l'ai compris à l'aide de ne question similaire sur serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;
75
punkish

Vous avez trouvé le raccourci pour définir les privilèges de toutes les tables existantes dans le schéma donné. Le manuel clarifie :

(mais notez que ALL TABLES est considéré comme incluant les vues et les tables étrangères ).

Gras accent mien. serial les colonnes sont implémentées avec nextval() sur une séquence comme colonne par défaut et, citant le manuel :

Pour les séquences, ce privilège permet d'utiliser les fonctions currval et nextval.

Donc, s'il y a serial colonnes, vous voudrez également accorder USAGE (ou ALL PRIVILEGES) sur séquences

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Remarque: colonnes d'identité , dans Postgres 10 ou ultérieur, utilise des séquences implicites ne nécessitant pas de privilèges supplémentaires. (Pensez à mettre à niveau les colonnes serial.)

Qu'en est-il des objets nouveaux?

Vous serez également intéressé par DEFAULT PRIVILEGES pour les utilisateurs ou les schémas :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Cela définit automatiquement les privilèges pour les objets créés ultérieurement, mais pas pour les objets préexistants.

Les privilèges par défaut sont seulement appliqués aux objets créés par l'utilisateur ciblé (FOR ROLE my_creating_role). Si cette clause est omise, l'utilisateur actuel exécutera ALTER DEFAULT PRIVILEGES Par défaut. Pour être explicite:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Notez également que toutes les versions de pgAdmin III ont un bogue subtil et les privilèges par défaut display dans le volet SQL, même s'ils ne s'appliquent pas au rôle actuel. Veillez à ajuster manuellement la clause FOR ROLE Lors de la copie du script SQL.

103
Erwin Brandstetter

Ma réponse est similaire à celui-ci sur ServerFault.com .

Être conservateur

Si vous voulez être plus conservateur que d’accorder "tous les privilèges", vous voudrez peut-être essayer quelque chose de plus semblable à ceux-ci.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

L'utilisation de public il fait référence au nom du schéma par défaut créé pour chaque nouvelle base de données/catalogue. Remplacez-le par votre propre nom si vous avez créé un schéma.

Accès au schéma

Pour accéder à un schéma, pour toute action, l'utilisateur doit disposer de droits "d'utilisation". Avant qu'un utilisateur puisse sélectionner, insérer, mettre à jour ou supprimer, il doit d'abord être autorisé à utiliser un schéma.

Vous ne remarquerez pas cette exigence lors de la première utilisation de Postgres. Par défaut, chaque base de données a un premier schéma nommé public. Et par défaut, chaque utilisateur s'est vu automatiquement attribuer des droits "d'utilisation" sur ce schéma particulier. Lorsque vous ajoutez un schéma supplémentaire, vous devez explicitement accorder des droits d'utilisation.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Extrait du Postgres doc :

Pour les schémas, autorise l'accès aux objets contenus dans le schéma spécifié (en supposant que les exigences en matière de privilèges de ces objets soient également remplies). Cela permet essentiellement au bénéficiaire de "rechercher" des objets dans le schéma. Sans cette autorisation, il est toujours possible de voir les noms d'objet, par exemple. en interrogeant les tables système. En outre, après avoir révoqué cette autorisation, les moteurs existants peuvent avoir des instructions qui ont déjà effectué cette recherche. Il ne s'agit donc pas d'un moyen totalement sécurisé d'empêcher l'accès aux objets.

Pour plus de discussion, voir la question, Qu'est-ce que GRANT USAGE ON SCHEMA fait exactement? . Portez une attention particulière à la réponse par l'expert Postgres Craig Ringer .

Objets existants ou futurs

Ces commandes n'affectent que les objets existants. Les tables et autres que vous créez à l'avenir obtiennent les privilèges par défaut jusqu'à ce que vous réexécutiez les lignes ci-dessus. Voir le autre réponse de Erwin Brandstetter pour modifier les valeurs par défaut, affectant ainsi les objets futurs.

37
Basil Bourque