Privilégios Padrão

ALTER DEFAULT PRIVILEGES anexa modelos de concessão a objetos futuros criados por um papel específico em um esquema. Sem ele, cada migração deve lembrar de instruções GRANT manuais.

Receita

-- Executar como proprietário da migração (cria tabelas em deploy)
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_readers;
 
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_writers;
 
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT USAGE, SELECT ON SEQUENCES TO app_writers;

Quando usar isso: Inicialização de um novo esquema, integração de um novo papel de serviço ou correção de falhas recorrentes de "esqueci de GRANT" no deploy.

Exemplo de Trabalho

CREATE ROLE app_owner NOLOGIN;
CREATE ROLE app_migrator LOGIN PASSWORD 'vault';
GRANT app_owner TO app_migrator;
 
CREATE SCHEMA app AUTHORIZATION app_owner;
 
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  REVOKE ALL ON TABLES FROM PUBLIC;
 
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_readers;
 
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_writers;
 
-- A migração cria nova tabela - as concessões são aplicadas automaticamente
SET ROLE app_owner;
CREATE TABLE app.orders (id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY);
RESET ROLE;
 
-- Verificar
SELECT grantee, privilege_type
FROM information_schema.table_privileges
WHERE table_schema = 'app' AND table_name = 'orders';

O que isso demonstra:

• FOR ROLE app_owner corresponde ao papel criador - detalhe crítico
• REVOKE ALL FROM PUBLIC nos padrões fecha o acesso público para novas tabelas
• A nova tabela orders já possui as concessões app_readers/app_writers

Análise Detalhada

FOR ROLE Importa

-- Errado: padrões para o usuário atual apenas
ALTER DEFAULT PRIVILEGES IN SCHEMA app GRANT SELECT ON TABLES TO app_ro;
 
-- Correto: padrões quando app_owner cria objetos
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_ro;

• Os padrões são indexados pelo papel criador do objeto, não apenas pelo proprietário do esquema.
• O migrador de CI deve consistentemente SET ROLE app_owner ou conectar como app_owner via SET SESSION AUTHORIZATION (apenas superusuário).
• Listar padrões configurados:

SELECT * FROM pg_default_acl;

Tipos de Objeto

Concessões Únicas Ainda Necessárias

-- Objetos existentes antes que os padrões fossem definidos
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_readers;

• ALTER DEFAULT PRIVILEGES não é retroativo.
• Scripts de inicialização de migração frequentemente combinam ALL TABLES + ALTER DEFAULT PRIVILEGES.

Armadilhas

• FOR ROLE Errado - O migrador é executado como app_migrator, mas os padrões são definidos para app_owner. Correção: Alinhar o papel criador ou adicionar padrões para ambos.
• Múltiplos Migradores - O usuário do Flyway versus o usuário de hotfix humano criam objetos sem padrões. Correção: Apenas um papel de migração em produção.
• Sequências Esquecidas - Concessões de tabela existem; INSERT falha em nextval. Correção: Privilégios padrão em SEQUENCES também.
• Esquema criado por superusuário - Os padrões para app_owner não se aplicam a tabelas criadas por superusuário. Correção: Nunca crie tabelas de aplicativos como superusuário.
• Teste apenas em esquema vazio - Os padrões nunca são testados até a segunda migração. Correção: CI cria duas tabelas e afirma as concessões.

Alternativas

FAQs

Relacionados

• Padrões GRANT/REVOKE - concessões únicas em objetos existentes
• Noções Básicas de Migrações - disciplina de papel de migração
• Melhores Práticas de Permissões - o aplicativo se conecta com o mínimo de privilégio

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.