Accorder des privilèges pour une base de données particulière dans PostgreSQL

Concept de base dans Postgres

Les rôles sont des objets globaux qui peuvent accéder à toutes les bases de données d'un cluster de base de données - avec les privilèges requis.

Un cluster contient de nombreuses bases de données , qui contiennent de nombreux schémas . Les schémas (même avec le même nom) dans différentes bases de données ne sont pas liés. L'octroi de privilèges pour un schéma ne s'applique qu'à ce schéma particulier dans la base de données actuelle (la base de données actuelle au moment de l'octroi).

Chaque base de données commence par un schéma public par défaut. C'est une convention, et de nombreux paramètres commencent par elle. Autre que cela, le schéma public n'est qu'un schéma comme un autre.

Venant de MySQL, vous voudrez peut-être commencer avec un seul schéma public , en ignorant complètement la couche de schéma. J'utilise régulièrement des dizaines de schémas par base de données.
Les schémas sont un peu (mais pas complètement) comme des répertoires dans le système de fichiers.

Une fois que vous utilisez plusieurs schémas, assurez-vous de comprendre search_path réglage :

Comment le search_path influence-t-il la résolution de l'identifiant et le "schéma actuel"

Privilèges par défaut

Par documentation sur GRANT :

PostgreSQL accorde des privilèges par défaut sur certains types d'objets à PUBLIC . Aucun privilège n'est accordé à PUBLIC par défaut sur les tables, les colonnes, les schémas ou les tablespaces. Pour les autres types, les privilèges par défaut accordés à PUBLIC sont les suivants :CONNECT et CREATE TEMP TABLE pour les bases de données ; EXECUTE privilège pour les fonctions; et USAGE privilège pour les langues.

Tous ces paramètres par défaut peuvent être modifiés avec ALTER DEFAULT PRIVILEGES :

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

Rôle de groupe

Comme @Craig l'a commenté, il est préférable de GRANT privilèges à un rôle de groupe, puis rendre un utilisateur spécifique membre de ce rôle (GRANT le rôle de groupe au rôle d'utilisateur). De cette façon, il est plus simple de distribuer et de révoquer des ensembles de privilèges nécessaires pour certaines tâches.

Un rôle de groupe est juste un autre rôle sans connexion. Ajoutez une connexion pour la transformer en rôle d'utilisateur. Plus :

Pourquoi PostgreSQL a-t-il fusionné les utilisateurs et les groupes en rôles ?

Rôles prédéfinis

Mise à jour : Postgres 14 ou version ultérieure ajoute les nouveaux rôles prédéfinis (formellement "rôles par défaut") pg_read_all_data et pg_write_all_data pour simplifier certains des éléments ci-dessous. Voir :

Accorder l'accès à toutes les tables d'une base de données

Recette

Dites, nous avons une nouvelle base de données mydb , un groupe mygrp , et un utilisateur myusr ...

Lorsque vous êtes connecté à la base de données en question en tant que superutilisateur (postgres par exemple):

REVOKE ALL ON DATABASE mydb FROM public;  -- shut out the general public
GRANT CONNECT ON DATABASE mydb TO mygrp;  -- since we revoked from public

GRANT USAGE ON SCHEMA public TO mygrp;

Pour attribuer "un utilisateur tous les privilèges sur toutes les tables" comme vous l'avez écrit (je suis peut-être plus restrictif) :

GRANT ALL ON ALL TABLES IN SCHEMA public TO mygrp;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO mygrp; -- don't forget those

Pour définir des privilèges par défaut pour les futurs objets, exécutez pour chaque rôle qui crée des objets dans ce schéma :

ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON TABLES TO mygrp;

ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON SEQUENCES TO mygrp;

-- more roles?

Maintenant, accordez le groupe à l'utilisateur :

GRANT mygrp TO myusr;

Réponse connexe :

PostgreSQL - L'utilisateur de la base de données ne devrait être autorisé qu'à appeler des fonctions

Paramètre alternatif (non standard)

Venant de MySQL, et puisque vous souhaitez séparer les privilèges sur les bases de données, vous aimerez peut-être ce paramètre non standard db_user_namespace . Par documentation :

Ce paramètre active les noms d'utilisateur par base de données. Il est désactivé par défaut.

Lisez attentivement le manuel. Je n'utilise pas ce paramètre. Cela n'annule pas ce qui précède.