En utilisant PostgreSQL 9.0, j'ai un rôle de groupe appelé "staff" et j'aimerais 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 du "staff" sont toujours incapables de SELECT ou UPDATE sur les tables individuelles dans le schéma "foo" ou (dans le cas de la deuxième commande) à n'importe quelle table dans la base de données à moins que j'accorde tout sur cette table spécifique.

Que puis-je faire pour faciliter ma vie et celle de mes utilisateurs?

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

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

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

(mais notez que cela ALL TABLESinclut des vues et des tables étrangères ).

Je souligne le mien. serialles colonnes sont implémentées avec nextval()sur une séquence comme colonne par défaut et, en citant le manuel :

Pour les séquences, ce privilège permet l'utilisation des fonctions currvalet nextval.

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

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Remarque: les colonnes d'identité dans Postgres 10 ou version ultérieure utilisent des séquences implicites qui ne nécessitent pas de privilèges supplémentaires. (Pensez à mettre à niveau les serialcolonnes.)

Et les nouveaux objets?

Vous serez également intéressé DEFAULT PRIVILEGESpar 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 à l'avenir, mais pas pour les objets préexistants.

Les privilèges par défaut ne sont appliqués qu'aux objets créés par l'utilisateur ciblé ( FOR ROLE my_creating_role). Si cette clause est omise, elle utilise par défaut l'utilisateur en cours d'exécution ALTER DEFAULT PRIVILEGES. 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 affichent les privilèges par défaut dans le volet SQL, même s'ils ne s'appliquent pas au rôle actuel. Veillez à ajuster la FOR ROLEclause manuellement lors de la copie du script SQL.

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

Être conservateur

Si vous voulez être plus conservateur que d'accorder «tous les privilèges», vous pouvez essayer quelque chose de plus comme celui-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 publiclà 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 des droits "d'utilisation". Avant qu'un utilisateur puisse sélectionner, insérer, mettre à jour ou supprimer, un utilisateur doit d'abord se voir accorder une "utilisation" d'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 chaque utilisateur par défaut a reçu automatiquement les droits "d'utilisation" de 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 de la doc Postgres :

Pour les schémas, autorise l'accès aux objets contenus dans le schéma spécifié (en supposant que les exigences de privilège propres aux objets sont également satisfaites). 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 des objets, par exemple en interrogeant les tables système. De plus, après la révocation de cette autorisation, les backends existants peuvent avoir des instructions qui ont précédemment 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, que fait exactement l'utilisation des subventions sur le schéma? . Portez une attention particulière à la réponse de l'expert de Postgres Craig Ringer .

Objets existants et futur

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 ces lignes ci-dessus. Voir l' autre réponse d'Erwin Brandstetter pour changer les valeurs par défaut affectant ainsi les objets futurs.