Privilégios para o proprietário do banco de dados; usuário do aplicativo

Versão rápida:

Qual comando devo emitir para permitir que um proprietário de banco de dados permita acessar tabelas nesse banco de dados e isso pode ser feito a partir da conta desse proprietário?

Versão mais longa:

Estou criando um banco de dados no RDS. Eu tenho um usuário 'raiz' que configurei com a Amazon.

A Amazon cria automaticamente a função de grupo 'rds_superuser', que é muito privilegiada, mas na verdade não é um superusuário.

Estou criando um banco de dados e um usuário para o aplicativo da seguinte maneira:

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;

Atualizei este script para refletir sugestões de Craig Ringer sobre como eu deveria lidar com isso.

Quando o aplicativo se conecta (com as credenciais master_application), ele cria (e, portanto, é o proprietário) das tabelas.

Meu problema é que não consigo usar meu logon administrativo (raiz) para executar consultas, porque esse usuário não tem privilégios na tabela.

Consegui resolver isso antes executando o seguinte na conta do aplicativo:

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

Mas parece hacky ter um usuário subordinado conceder privs de volta a um usuário administrativo.

Então ... Existe um comando que eu possa executar antes ou depois de criar as tabelas a partir do aplicativo que garantirá que o proprietário do banco de dados possa acessar as tabelas no banco de dados?

atualizar após tentar novamente os privilégios padrão de alteração ...

Isso ainda não concede acesso às tabelas; Eu vejo isso sendo sugerido em outro lugar e faz todo sentido, mas não está funcionando para mim. Em um 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 é meu usuário superusuário-ish e users é uma tabela dentro do meu banco de dados.

Atualizar

Eu recebi uma resposta bastante inútil de alguém na Amazon.

Eles me pediram para ligar para ALTER PRIVILEGES PADRÃO no login master_application. Embora isso provavelmente funcione, ele não responderia à minha pergunta (que é como eu faço isso acontecer apenas da conta rds_superuser).

Pedi-lhes para esclarecer isso e eles foram embora.

Você quer ALTER DEFAULT PRIVILEGES.

Conceda os rds_superuserdireitos de acesso padrão a todas as novas tabelas.

Isso afeta apenas as tabelas criadas após o ALTER. Para tabelas existentes, você deve GRANTdireitos.

O esquema público deve ser visível por todos os usuários. Você não deve restringir os direitos do esquema público a apenas um grupo.

Então, se você não usar:

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

Você pode trabalhar com segurança com o esquema público em todas as contas.

Se você não deseja que contas específicas atrapalhem suas tabelas de esquema públicas, crie uma nova função (para os usuários do seu aplicativo) e revogue direitos dessa função específica dentro do esquema público. Algo como:

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)

Não o contrário, ao tentar fazer isso.