web-dev-qa-db-fra.com

Privilèges pour le propriétaire de la base de données; utilisateur de l'application

Version rapide:

Quelle commande dois-je émettre pour permettre à un propriétaire de base de données de lui permettre d'accéder aux tables de cette base de données et cela peut-il être fait à partir du compte de ce propriétaire?

Version plus longue:

Je crée une base de données sur RDS. J'ai un utilisateur "root" que j'ai configuré avec Amazon.

Amazon crée automatiquement le rôle de groupe "rds_superuser" qui est très privilégié, mais pas en fait un superutilisateur.

Je crée une base de données et un utilisateur pour l'application comme suit:

create database master_integration;
CREATE ROLE master_application LOGIN ENCRYPTED PASSWORD '...' VALID UNTIL 'infinity';
GRANT ALL ON DATABASE master_integration TO GROUP rds_superuser WITH GRANT OPTION;
GRANT ALL ON DATABASE master_integration TO GROUP master_application;

\c master_integration;
ALTER DEFAULT PRIVILEGES GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ON TABLES TO rds_superuser;

J'ai mis à jour ce script pour refléter les suggestions de Craig Ringer concernant la façon dont je devrais gérer cela.

Lorsque l'application se connecte (avec les informations d'identification master_application), elle crée (et possède donc) les tables.

Mon problème est que je ne peux pas utiliser ma connexion administrative (rootish) pour exécuter des requêtes car cet utilisateur n'a aucun privilège sur la table.

J'ai pu résoudre ce problème auparavant en exécutant ce qui suit à partir du compte d'application:

GRANT ALL privileges ON ALL TABLES IN SCHEMA public to rds_superuser;

Mais il semble bizarre qu'un utilisateur subordonné accorde des privilèges à un utilisateur administratif.

Alors ... Y a-t-il une commande que je peux exécuter avant ou après avoir créé les tables à partir de l'application qui garantira que le propriétaire de la base de données peut accéder aux tables dans la base de données?

mise à jour après avoir réessayé les privilèges alter default ...

Cela n'accorde toujours pas l'accès aux tables; Je vois que cela est suggéré ailleurs et c'est tout à fait logique, mais cela ne fonctionne pas pour moi. Depuis un shell psql:

master_integration=> \ddp
                           Default access privileges
      Owner       | Schema | Type  |             Access privileges             
------------------+--------+-------+-------------------------------------------
 integration_root |        | table | integration_root=arwdDxt/integration_root+
                  |        |       | rds_superuser=arwdDxt/integration_root
(1 row)

master_integration=> \dp users
                           Access privileges
 Schema | Name  | Type  | Access privileges | Column access privileges 
--------+-------+-------+-------------------+--------------------------
 public | users | table |                   | 
(1 row)

integration_root est mon utilisateur superutilisateur et is users est une table dans ma base de données.

Mise à jour

J'ai reçu une réponse assez inutile de quelqu'un d'Amazon.

Ils m'ont demandé d'appeler ALTER DEFAULT PRIVILEGES à partir de la connexion master_application. Bien que cela fonctionnerait probablement, cela ne répondrait pas à ma question (qui est de savoir comment puis-je y arriver uniquement à partir du compte rds_superuser).

Je leur ai demandé de clarifier cela et ils sont partis.

postgresqlamazon-rds
15
Andy Davis

Tu veux ALTER DEFAULT PRIVILEGES .

Donner la rds_superuser droits d'accès par défaut à toutes les nouvelles tables.

Cela n'affecte que les tables créées après le ALTER. Pour les tables existantes, vous devez disposer des droits GRANT.

9
Craig Ringer

Le schéma public est censé être visible par tous les utilisateurs. Vous ne devez pas limiter les droits du schéma public à un seul groupe.

Donc, si vous n'utilisez pas:

GRANT ALL ON SCHEMA public TO GROUP rds_superuser WITH GRANT OPTION;

Vous pouvez travailler en toute sécurité avec le schéma public avec tous les comptes.

Si vous ne voulez pas que des comptes spécifiques gâchent vos tables de schéma public, créez un nouveau rôle (pour les utilisateurs de votre application) et révoquez les droits de ce rôle particulier dans le schéma public. Quelque chose comme:

CREATE USER mywebuser WITH PASSWORD '*****';
REVOKE ALL PRIVILEGES ON SCHEMA public FROM mywebuser;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mywebuser; (or whatever rights you need to provide)

Pas l'inverse lorsque vous essayez de le faire.

0
Alexandros