Tout d'abord, vous devez pouvoir vous connecter à la base de données pour pouvoir exécuter des requêtes. Ceci peut être réalisé en
REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;
GRANT CONNECT
ON DATABASE database_name
TO user_name;
Le REVOKE
est nécessaire car
Le mot clé PUBLIC indique que les privilèges doivent être accordés à tous les rôles, y compris ceux pouvant être créés ultérieurement. PUBLIC peut être considéré comme un groupe défini implicitement, qui inclut toujours tous les rôles. Tout rôle particulier aura la somme des privilèges qui lui sont directement attribués, des privilèges accordés à tout rôle dont il est actuellement membre et des privilèges accordés à PUBLIC.
Si vous voulez vraiment limiter votre utilisateur aux instructions DML, vous avez un peu plus à faire:
REVOKE ALL
ON ALL TABLES IN SCHEMA public
FROM PUBLIC;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public
TO user_name;
Celles-ci supposent que vous n'ayez qu'un seul schéma (nommé "public" par défaut).
Comme Jack Douglas l'a souligné, ce qui précède ne donne que les privilèges pour les tables déjà existantes . Pour obtenir la même chose pour les futures tables, vous devez définir les privilèges par défaut :
ALTER DEFAULT PRIVILEGES
FOR ROLE some_role -- Alternatively "FOR USER"
IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user_name;
Voici some_role
un rôle qui crée les tables, alors que user_name
c'est celui qui obtient les privilèges. Pour le définir, vous devez être connecté en tant some_role
que membre.
Et, enfin, vous devez faire la même chose pour les séquences (merci à PlaidFan de l'avoir signalé) - ici, c'est le USAGE
privilège dont vous avez besoin.
FOR some_role
c’était l’élément clé qui me manquait pour que cela fonctionne pour mes tables créées plus tard. Mais je n'avais pas besoin d'être connecté en tant que telsome_role
, cela fonctionnait également si j'exécutais la requête en tantpostgres
qu'utilisateur admin par défaut .