PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

PostgreSQL :donner toutes les autorisations à un utilisateur sur une base de données PostgreSQL

Toutes les commandes doivent être exécutées en étant connecté au bon cluster de bases de données. Assurez-vous-en.

Les rôles sont des objets de la base de données cluster . Toutes les bases de données d'un même cluster partagent l'ensemble des rôles définis. Les privilèges sont accordés/révoqués par base de données/schéma/table etc.

Un rôle doit accéder à la base de données , évidemment. C'est accordé à PUBLIC par défaut. Sinon :

GRANT CONNECT ON DATABASE my_db TO my_user;

Privilèges de base pour Postgres 14 ou version ultérieure

Postgres 14 ajoute les rôles prédéfinis sans connexion pg_read_all_data / pg_write_all_data .
Ils ont SELECT / INSERT , UPDATE , DELETE privilèges pour tous tables, vues et séquences. Plus USAGE sur les schémas. Nous pouvons GRANT appartenance à ces rôles :

GRANT pg_read_all_data TO my_user;
GRANT pg_write_all_data TO my_user;

Cela couvre toutes les commandes DML de base (mais pas DDL, et pas certaines commandes spéciales comme TRUNCATE ou le EXECUTE privilège pour les fonctions !). Le manuel :

pg_read_all_data

Lire toutes les données (tables, vues, séquences), comme si vous aviez SELECT droits sur ces objets, et USAGE droits sur tous les schémas, même sans l'avoir explicitement. Ce rôle n'a pas l'attribut de rôle BYPASSRLS Positionner. Si RLS est utilisé, un administrateur peut souhaiter définir BYPASSRLS sur les rôles dont ce rôle est GRANT ed to.

pg_write_all_data

Écrivez toutes les données (tables, vues, séquences), comme si vous aviez INSERT ,UPDATE , et DELETE droits sur ces objets, et USAGE droits sur tous les schémas, même sans l'avoir explicitement. Ce rôle n'a pas l'attribut de rôle BYPASSRLS Positionner. Si RLS est utilisé, un administrateur peut souhaiter définir BYPASSRLS sur les rôles dont ce rôle estGRANT ed to.

Tous les privilèges sans utiliser de rôles prédéfinis (toute version de Postgres)

Les commandes doivent être exécutées en étant connecté à la bonne base de données. Assurez-vous-en.

Le rôle a besoin (au moins) du USAGE privilège sur le schéma . Encore une fois, si cela est accordé à PUBLIC , vous êtes couvert. Sinon :

GRANT USAGE ON SCHEMA public TO my_user;

Ou accordez USAGE sur tous schémas personnalisés :

DO
$$
BEGIN
   -- RAISE NOTICE '%', (  -- use instead of EXECUTE to see generated commands
   EXECUTE (
   SELECT string_agg(format('GRANT USAGE ON SCHEMA %I TO my_user', nspname), '; ')
   FROM   pg_namespace
   WHERE  nspname <> 'information_schema' -- exclude information schema and ...
   AND    nspname NOT LIKE 'pg\_%'        -- ... system schemas
   );
END
$$;

Ensuite, toutes les autorisations pour toutes les tables (nécessite Postgres 9.0 ou plus tard).
Et n'oubliez pas les séquences (le cas échéant) :

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO my_user;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO my_user;

Alternativement, vous pouvez utiliser le "Grant Wizard" de pgAdmin 4 pour travailler avec une interface graphique.

Il y a quelques autres objets, le manuel pour GRANT a la liste complète. Depuis Postgres 12 :

privilèges sur un objet de base de données (table, colonne, vue, table étrangère, séquence, base de données, wrapper de données étrangères, serveur étranger, fonction, procédure, langage procédural, schéma ou tablespace)

Mais le reste est rarement nécessaire. Plus de détails :

  • Comment gérer les PRIVILÈGES PAR DÉFAUT pour les UTILISATEURS sur une BASE DE DONNÉES vs SCHEMA ?
  • Accorder des privilèges pour une base de données particulière dans PostgreSQL
  • Comment accorder tous les privilèges sur les vues à un utilisateur arbitraire

Envisagez de passer à une version actuelle.