PostgreSQL: autorisation refusée pour la relation

14

Je suis un peu confus quant à la définition des autorisations dans PostgreSQL.

J'ai ces rôles:

                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 admin     | Superuser, Create role, Create DB, Replication | {}
 meltemi   | Create role, Create DB                         | {rails}
 rails     | Create DB, Cannot login                        | {}
 myapp     |                                                | {rails}

et bases de données:

                                    List of databases
        Name         | Owner  | Encoding |   Collate   |    Ctype    | Access privileges 
---------------------+--------+----------+-------------+-------------+-------------------
 myapp_production    | rails  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 ...

l'utilisateur myappn'a aucun problème à interroger la myapp_productionbase de données en ajoutant et en supprimant des enregistrements. J'aimerais meltemiégalement pouvoir interroger la même base de données. Donc, j'ai créé un rôle railsqui possède la base de données et fait les deux meltemiet les myappmembres de rails. Mais je reçois toujours des permission denied for relationerreurs. Meltemipeut afficher le schéma mais ne peut pas interroger la base de données.

Je viens de remarquer (avec \dtcommande) quemyapp c'est le propriétaire des tables:

             List of relations
 Schema |       Name        | Type  | Owner 
--------+-------------------+-------+-------
 public | events            | table | myapp
 public | schema_migrations | table | myapp
 ...
 public | users             | table | myapp
 ...

Les tables ont été créées via un ORM (migrations ActiveRecord de Rails).

Je sais que l'autorisation est très différente dans PostgreSQL (par opposition à MySQL et autres que j'ai utilisés). Comment dois-je configurer ma base de données pour que différents utilisateurs puissent y accéder. Certains devraient être capables de CRUD mais d'autres peuvent seulement lire, etc ...

Merci pour toute aide. Désolé, je sais que c'est une question très basique mais je n'ai pas pu trouver la réponse moi-même.

postgresql permissions role authorization Meltemi
la source

Réponses:

4

Je viens d'écrire à ce sujet dans ma réponse à l' octroi de droits sur la base de données postgresql à un autre utilisateur sur ServerFault.

Fondamentalement, la meilleure solution lorsque vous avez un seul utilisateur et que vous souhaitez accorder les mêmes droits à d'autres utilisateurs est de transformer cet utilisateur en groupe, de créer un nouvel utilisateur avec le même nom que celui d'origine qui est membre du groupe, et accorder ce groupe à d'autres utilisateurs également.

Donc, dans votre cas, railsest renommé pour dire myapp_users, puis vous créez un nouveau rôle de connexion (utilisateur) nommé railset GRANT myapp_users TO rails. Maintenant tu es GRANT myapp_users TO meltemi. Le nouveau railscompte et l' meltemiutilisateur ont désormais les droits de l'ancien railscompte.

Pour un contrôle plus fin, je vous conseille généralement d'éviter de donner aux utilisateurs de connexion au jour le jour ou à leurs groupes la propriété des tables. Donnez-leur accès via un NOINHERITgroupe auquel ils doivent explicitement SET GROUP, ou mieux, utiliser un utilisateur complètement différent pour des opérations privilégiées comme DDL et GRANTs. Malheureusement, cela ne fonctionne pas avec Rails, car Rails aime appliquer les migrations quand il le souhaite et AFAIK ne vous donne pas la possibilité de spécifier un utilisateur différent et plus privilégié pour exécuter les migrations.

Craig Ringer
la source
OK, lisez le message auquel vous avez lié; très utile! Maintenant, si je comprends bien, je pense que vous avez peut-être voulu utiliser myappau lieu de railsci-dessus? Parce que myapppossède les tables (je n'ai jamais spécifié cela, la migration doit avoir). Quoi qu'il en soit, il serait sorta logique si je renomme myappà myapp_grouppuis fait un nouvel utilisateur myappqui les rails app utiliseraient pour se connecter à la DB. Make myappet l'existant meltemi, les deux membres du myapp_grouprôle. Mais que se passe-t-il lorsque j'exécute la prochaine migration. ne sera-t-il pas la propriété de myapprecréer le problème à nouveau?!?
Meltemi
1
Vous devez comprendre que PostgreSQL ne dispose que roles(depuis la version 8.1). Les termes useret groupsont conservés pour des raisons historiques et de compatibilité. Fondamentalement, un "groupe" est un rôle sans le privilège de connexion. Vous pouvez accorder myappà meltemimême si myappc'est juste un autre "utilisateur". Commencez par lire le manuel ici .
Erwin Brandstetter
Je comprends la séparation rolesvs groupsvs usersdans Postgres, du moins je pense que je le sais. Désolé d'utiliser la mauvaise terminologie (et la confusion) ci-dessus. Mais je ne comprends toujours pas comment configurer ma base de données, donc un rôle sans connexion OWNS la base de données et deux rôles de connexion myappet meltemipeuvent tous deux avoir un accès complet. L'un de ces rôles myappexécutera des migrations Rails qui, inévitablement?, Créeront de nouvelles tables qui, une fois de plus, appartiennent à myappun utilisateur de connexion. Dois-je simplement en devenir meltemiun "membre" myappet en finir avec cela? Mais cela semble juste maladroit ... non?!?
Meltemi
1
@Meltemi: Si vous voulez accorder tous les privilèges qui vous myapptiennent meltemi, alors ce serait la bonne chose à faire. Si vous ne souhaitez meltemiobtenir qu'un sous-ensemble de privilèges, ce n'est pas le cas. Créez ensuite un rôle de groupe pour détenir l'ensemble de privilèges et accordez-le à meltemi. Vous serez très probablement intéressé par cette question connexe sur SO . J'ai répondu en expliquantDEFAULT PRIVILEGES
Erwin Brandstetter
@Meltemi Oui, comme d'habitude les migrations Rails compliquent l'image. Rails devrait vraiment vous permettre de spécifier un autre compte utilisateur pour exécuter les migrations. Vous pouvez éventuellement ajouter une SET ROLEcommande au début de vos migrations et une RESET ROLEà la fin, mais je ne ferais pas confiance à Rails pour exécuter le tout correctement dans l'ordre. Erwin a raison; dans ce cas, la meilleure solution consistera à GRANTce que les rails utilisateur confèrent la propriété à l'autre utilisateur, en utilisant le premier utilisateur comme groupe pour le second.
Craig Ringer