web-dev-qa-db-fra.com

Postgresql: que fait GRANT ALL PRIVILEGES ON DATABASE?

J'essaie d'accorder tous les privilèges sur toutes les tables d'une base de données donnée à un nouvel utilisateur postgres (pas le propriétaire). Il paraît que GRANT ALL PRIVILEGES ON DATABASE my_db TO new_user; ne fait pas ça. Après avoir exécuté ladite commande avec succès (en tant qu'utilisateur postgres), j'obtiens ce qui suit en tant que new_user:

$ psql -d my_db
my_db => SELECT * FROM a_table_in_my_db;
ERROR:  permission denied for relation a_table_in_my_db

Deux questions:

1) Que fait alors la commande ci-dessus si elle n'accorde pas toutes les autorisations sur toutes les tables de my_db?

2) Quelle est la bonne façon d'accorder toutes les autorisations sur toutes les tables à un utilisateur? (y compris sur toutes les tables créées à l'avenir)

permissionssqlpostgresql
65
rz.

Les réponses à vos questions proviennent des documentation PostgreSQL 8.4 en ligne .

  1. GRANT ALL PRIVILEGES ON DATABASE accorde les privilèges CREATE, CONNECT et TEMPORARY sur une base de données à un rôle (les utilisateurs sont correctement appelés rôles ). Aucun de ces privilèges ne permet en fait à un rôle de lire les données d'une table; SELECT le privilège sur la table est requis pour cela.

  2. Je ne suis pas sûr qu'il existe un moyen "approprié" d'accorder tous les privilèges sur toutes les tables à un rôle. La meilleure façon de s'assurer qu'un rôle donné possède tous les privilèges sur une table est de s'assurer que le rôle possède la table. Par défaut, chaque objet nouvellement créé appartient au rôle qui l'a créé. Par conséquent, si vous souhaitez qu'un rôle ait tous les privilèges sur une table, utilisez ce rôle pour le créer.

    PostgreSQL 9.0 introduit la syntaxe suivante qui est presque ce que vous voulez:

    GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;

    Le hic, c'est que si vous créez des tables dans des schémas en dehors du schéma "public" par défaut, ce GRANT ne leur sera pas applicable. Si vous utilisez des schémas non publics, vous devrez GRANT les privilèges de ces schémas séparément.

87
Steven Monday

Il est possible de configurer plusieurs connexions pour agir en tant que propriétaire de la base de données:

  • Créez un rôle "nologin" pour agir en tant que propriétaire: create role dbowner nologin
  • Remplacez le propriétaire de votre base de données par: alter database mydb owner dbowner
  • Accordez toutes vos connexions à ce nouveau rôle: grant dbowner to user1, user2

Désormais, si l'utilisateur1 ou l'utilisateur2 se connecte, ils ont toutes les autorisations sur "mydb" sans aucune autre autorisation requise.

Cependant, je considérerais cette solution attentivement. Il est tentant que votre application Web utilise l'une de ces connexions pour éviter la douleur de créer des autorisations supplémentaires chaque fois que le schéma est mis à jour, mais vous supprimez une forme de protection très utile de cette façon. Utilisez la solution ci-dessus si vous voulez vraiment plusieurs "administrateurs", mais respectez le modèle "accorder tous les privilèges sur toutes les tables du schéma ..." ci-dessus pour la connexion à votre application "utilisation normale".

12
Chris Cogdon