sqlpostgresqlcreate-rolepermissions

CREATE ROLE no PostgreSQL: usuarios, grupos e heranca de permissoes

Como uma unica instrucao CREATE ROLE modela pessoas e grupos: LOGIN versus NOLOGIN, pertinencia a roles, heranca e atributos como CREATEDB.

3 min de leituraReferencesql · postgresql · create-role · permissions · security · users

O PostgreSQL nao tem entidades separadas de "usuario" e "grupo": existe um unico role universal. A instrucao CREATE ROLE cria tanto a pessoa que faz login quanto o grupo que guarda os privilegios para os demais. A unica diferenca esta nos atributos que voce anexa.

Um role de login e um role de grupo

Um role com o atributo LOGIN pode se conectar ao servidor, que e o que costumamos chamar de "usuario". Um role sem LOGIN nao pode se conectar e geralmente serve como container de privilegios, ou seja, um "grupo".

-- a login role: an actual person or service
CREATE ROLE analyst LOGIN PASSWORD 'secret';

-- a group role: no login, just holds privileges
CREATE ROLE app_readonly NOLOGIN;

CREATE USER e apenas um sinonimo de CREATE ROLE ... LOGIN. Entao CREATE USER analyst e CREATE ROLE analyst LOGIN fazem exatamente a mesma coisa; nao existe nenhum "tipo de usuario" separado por baixo.

Vamos dar ao grupo acesso de leitura ao nosso esquema:

GRANT SELECT ON users, orders, employees TO app_readonly;

Pertinencia a roles e heranca

Um role passa a ser membro de um grupo com GRANT role TO member. Dai em diante o atributo INHERIT decide tudo: se ele estiver ativo (o padrao), o membro usa automaticamente os privilegios do grupo.

-- analyst now inherits everything app_readonly can do
GRANT app_readonly TO analyst;

-- as analyst, this just works thanks to inheritance:
SELECT country, count(*) FROM users GROUP BY country;

Se o role for criado com NOINHERIT, os privilegios do grupo nao se aplicam automaticamente; voce precisa "vesti-los" de forma explicita com SET ROLE:

CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret';
GRANT app_readonly TO deploy_bot;

-- without SET ROLE the SELECT below is denied
SET ROLE app_readonly;
SELECT amount FROM orders WHERE status = 'paid';
RESET ROLE;

Pegadinha: atributos como SUPERUSER, CREATEDB e LOGIN NUNCA sao herdados por pertinencia. Um membro de um grupo superusuario nao se torna superusuario. Apenas os privilegios comuns (SELECT, INSERT e assim por diante) sao herdados, nunca os atributos do role.

Atributos do role

Os atributos definem o que um role pode fazer no nivel de todo o cluster. Os mais comuns:

  • LOGIN / NOLOGIN controla se o role pode se conectar ao servidor.
  • SUPERUSER / NOSUPERUSER decide se o role ignora todas as verificacoes de permissao. Distribua com muita parcimonia.
  • CREATEDB permite ao role criar bancos de dados.
  • CREATEROLE permite ao role criar e alterar outros roles.
  • PASSWORD e VALID UNTIL definem a senha e sua data de expiracao.
CREATE ROLE etl_owner LOGIN
    CREATEDB
    PASSWORD 'secret'
    VALID UNTIL '2026-12-31';

Voce pode alterar os atributos depois com ALTER ROLE, que tambem e o jeito pratico de revogar poderes perigosos:

ALTER ROLE analyst CONNECTION LIMIT 5;
ALTER ROLE etl_owner NOCREATEDB;

O modelo de "usuarios e grupos"

Um padrao pratico: crie alguns roles de grupo para conjuntos de privilegios, crie as pessoas como roles de login e conecte-os por pertinencia. Mudar o acesso depois e um unico GRANT / REVOKE, nao editar permissoes tabela a tabela para cada individuo.

-- groups by responsibility
CREATE ROLE readers NOLOGIN;
CREATE ROLE writers NOLOGIN;

GRANT SELECT ON users, orders TO readers;
GRANT SELECT, INSERT, UPDATE ON orders TO writers;

-- writers should also be able to read
GRANT readers TO writers;

-- people
CREATE ROLE maria LOGIN PASSWORD 'secret';
CREATE ROLE pavel LOGIN PASSWORD 'secret';

GRANT readers TO maria;
GRANT writers TO pavel;

Quando o Pavel sai da equipe de escrita, voce executa REVOKE writers FROM pavel e o acesso e retirado de todas as tabelas de uma vez.

Diferencas entre os bancos:

  • MySQL nao tinha roles antes da 8.0; agora tem CREATE ROLE e CREATE USER, mas sao comandos distintos, e o role ainda precisa ser ativado com SET ROLE ou SET DEFAULT ROLE.
  • ClickHouse suporta CREATE ROLE, CREATE USER e GRANT, mas o modelo de privilegios e mais plano, sem heranca profunda por cadeias de roles.

A regra base: anexe os privilegios aos grupos, torne as pessoas membros dos grupos e reserve SUPERUSER apenas para os administradores da plataforma.

Pratique com exercícios reais

Resolva exercícios no treinador de SQL com correção instantânea e dicas.

Abrir o treinador