Conceitos básicos

Até a versão 8.1, os conceitos de usuários e de grupos administrativos eram distintos em PostgreSQL. Esses conceitos foram abstraídos e absorvidos por uma única entidade chamada "role".

A palavra "role", em inglês, significa cargo (no sentido de função) ou "papel" (no sentido de "como atua"). Assim, uma role descreve seu próprio papel e quais as funções em que ela atua no contexto da segurança do banco de dados.

De modo abstrato, uma role pode se comportar como um usuário, como um grupo ou ter ambos comportamentos ao mesmo tempo. A role pode conter e ser contida por outra role. Deste modo, fica claro que o conceito de role está relacionado com a definição de permissões, privilégios e garantias de acesso aos objetos do banco e aos dados.

Roles podem ser donas de seus próprios objetos (tabelas) e podem delegar permissões ou direitos para outras roles através de herança e relacionamentos de confiança.

Os privilégios dados em roles, são completamente distintos dos privilégios dados no sistema de arquivos. Muitas vezes, pode ser conveniente manter uma relação entre privilégios dos objetos do banco e privilégios do sistema de arquivos, mas isso não é obrigatório. As roles possuem um contexto global relativo ao cluster do banco. Isso significa que elas existem em todos os bancos de dados criados no cluster. Cada role é identificada por um nome exclusivo dentro do cluster, ou seja, cada role deve ser única.

Os nomes das roles seguem o padrão léxico para criação de identificadores de objetos em PostgreSQL. O nome do identificador DEVE começar com uma letra [a-z], seguida de outros caracteres, incluindo letras acentuadas ou sinais não latinos, caracteres numéricos [0-9] e o sinal de sublinhado (underscore), que também é válido.

Por questão de bom senso, é recomendado ficar restrito aos caracteres minúsculos da tabela ASCII [a-z] evitando nomes que sejam válidos, porém estranhos. O interessante, é que as regras léxicas para identificadores são iguais às regras léxicas para comandos da linguagem SQL.

Deste modo, não é possível diferenciar um comando SQL de um identificador criado pelo usuário, se você não conhecer bem a linguagem. Na teoria, não existe limite para o tamanho do nome identificador. Na prática, o identificador será truncado em 63 caracteres que representa o máximo de caracteres permitidos.

Os comandos SQL não são sensíveis à caixa alta (case-insensitive), mas as boas práticas recomendam escrever os comandos SQL com letras maiúsculas e os identificadores em minúsculas. Isso torna o código legível para humanos.

Um identificador especial entre aspas duplas pode ser criado. E isso permite, por exemplo, criar um identificador "select" sem entrar em conflito com a palavra reservada SELECT do SQL. Assim, é possível construir identificadores que, de outra forma, não seriam possíveis, tais como identificadores que incluem espaços em branco ou traços. Esta técnica é uma questão de estilo e pode tornar seu código menos portável e menos legível.

Quando PostgreSQL é instalado através de um pacote, uma role com atribuições administrativas é automaticamente configurada. Essa role equivale ao usuário root dos sistemas GNU/Linux.

Todas as permissões administrativas são concedidas para essa role. Normalmente, pensamos nela como um superusuário administrativo. Essa role especial, quase sempre, é identificada pelo nome de postgres.

Como fazemos com root no GNU/Linux, no PostgreSQL devemos evitar o login com a role postgres. Crie e utilize outras roles administrativas com poderes limitados ao contexto de uso de cada banco de dados.

* Lembre-se que a role postgres possui todos os poderes administrativos, incluindo aqueles que podem destruir o ambiente dos bancos de dados. Para obter uma listagem de todas as roles, utilize a ferramenta psql e dê o seguinte comando SQL para consultar a tabela "pg_roles":

postgres=# SELECT rolname FROM pg_roles;
<sub>arolname
----------
postgres

(1 registro)</sub>

Para obter uma listagem dos privilégios de cada role, use o meta-comando da ferramenta psql com \dg, ou seu equivalente com \du:

postgres=# \du

                                Lista de roles

 Nome da role |                   Atributos                   | Membro de

 -------------+-----------------------------------------------+-----------

 postgres     | Super-usuário, Cria role, Cria BD, Replicação | {}

No Debian, a instalação de PostgreSQL cria o usuário postgres sem uma senha de login. Isto é proposital, já que o usuário é utilizado apenas para administrar o cluster de bancos.

Não há necessidade de senha, se o administrador do cluster dos bancos tiver a senha do root para fazer su ou utilizar sudo para administrar com elevação de privilégios. O usuário postgres não tem uma "casa" em /home e não deve ter senha de login.

A entrada em /etc/passwd mostra o usuário postgres no Debian Jessie:


Qualquer conexão a um banco é feita em nome de uma role com permissão de login. Com psql, por exemplo, devemos especificar a role (como se fosse um usuário) com o argumento -U nome_da_role ou --username=nome_da_role.

Muitos utilitários podem supor (incluindo psql) que o usuário do banco é o mesmo do sistema, então, seja sempre explícito quando estiver conectando a um banco. Manter uma relação de existência entre usuários do sistema de arquivos e roles não é obrigatório, e na verdade não traz benefício algum.

Criando roles

A criação de roles é uma prerrogativa de usuários que possuam a permissão "CREATEROLE", ou que sejam superusuários. No ambiente psql, o comando CREATE ROLE é responsável por essa tarefa. Vejamos sua sintaxe e funcionamento:

> \h CREATE ROLE;

• Comando: CREATE ROLE
• Descrição: define uma nova role do banco de dados
• Sintaxe: CREATE ROLE nome [ [ WITH ] opção [ ... ] ]

Onde opção, pode ser:

    | SUPERUSER   | NOSUPERUSER
    | CREATEDB    | NOCREATEDB
    | CREATEROLE  | NOCREATEROLE
    | CREATEUSER  | NOCREATEUSER
    | INHERIT     | NOINHERIT
    | LOGIN       | NOLOGIN
    | REPLICATION | NOREPLICATION
    | CONNECTION LIMIT limite_conexão
    | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'senha'
    | VALID UNTIL 'tempo_absoluto'
    | IN ROLE nome_role [, ...]
    | IN GROUP nome_role [, ...]
    | ROLE nome_role [, ...]
    | ADMIN nome_role [, ...]
    | USER nome_role [, ...]
    | SYSID uid

Nome_da_Role :: normalmente, o nome da role não é sensível à caixa de texto (case-insensitive), exceto quando esse nome é um identificador especial escrito entre aspas duplas. Neste caso, "select" é uma role e "SELECT" é outra e ambas podem coexistir. O comando CREATE ROLE possui diversas opções que são utilizadas para ativar ou desativar características da role no momento da criação. As opções são mutuamente excludentes. Assim, quando definimos SUPERUSER como ativo, automaticamente desativamos NOSUPERUSER. Na prática, há apenas um único valor binário do argumento que recebe verdadeiro (true) ou falso (false).

SUPERUSER | NOSUPERUSER :: define se a role possui ou não poderes de superusuário. Poderes de superusuário são perigosos e não devem ser atribuídos, a menos que essa realmente seja a função da role. Somente um superusuário pode criar outro superusuário. Por omissão, o padrão dessa opção é NOSUPERUSER.

CREATEDB | NOCREATEDB :: define se a role pode ou não criar novos bancos de dados no cluster. Por omissão, o padrão é NOCREATEDB.

CREATEROLE | NOCREATEROLE :: define que a role pode ou não criar outras roles. Uma role que tem essa permissão, também pode alterar (ALTER ROLE) e apagar roles (DROP ROLE), bem como garantir (GRANT) e revogar (REVOKE) participação em outras roles. Isoladamente, essa permissão não é suficiente para criar, alterar, excluir ou modificar a participação em uma role que seja superusuário. Apenas um superusuário pode modificar outro superusuário.

CREATEUSER | NOCREATEUSER :: essa é uma opção obsoleta (não existe mais o conceito de usuário!). Entretanto, ela ainda continua funcionando. Observe que ao contrário do que parece, ela não é equivalente a CREATE ROLE e sim a SUPERUSER | NOSUPERUSER.

INHERIT | NOINHERIT :: define se a role herda as propriedades das roles que participa como membro. Uma role que aceita herança, pode utilizar qualquer privilégio do banco de dados que estiver sendo garantido para todas as roles membro, diretamente ou indiretamente. Sem herança (NOINHERIT), uma role associada à outra, recebe apenas o privilégio SET ROLE para a outra role. Atenção, por omissão, o padrão é INHERIT.

LOGIN | NOLOGIN :: esta opção define que a role pode fazer login. Isso faz com que a role se comporte essencialmente como um usuário. Se LOGIN é definido, então o nome da role pode ser utilizado durante uma conexão como um parâmetro --username. Roles definidas como NOLOGIN, são consideradas essencialmente como administrativas e têm como função, gerenciar privilégios dos objetos do banco de dados. Por omissão, o padrão é NOLOGIN. Quando uma role é criada pelo comando CREATE USER, ela é sempre configurada com a propriedade LOGIN ativa, pois esse comando cria um superusuário.

REPLICATION | NOREPLICATION :: replicação é uma característica avançada do PostgreSQL, que permite distribuir os dados e manter uma cópia exata desses dados em outro local, mantendo a consistência de modo síncrono ou assíncrono. Replicação pode ser considerada um tipo de cópia de segurança (backup) em alguns casos. O privilégio da replicação é considerado de alto nível para a segurança do sistema e deve ser atribuído somente a roles que estejam envolvidas nesse processo. Por omissão, o padrão é NOREPLICATION.

CONNECTION LIMIT :: essa propriedade somente faz sentido para roles que podem fazer login. Sua função é definir quantas instâncias dessa role podem fazer login simultaneamente. Por omissão, o padrão é -1, que significa NENHUM LIMITE.

PASSWORD 'senha' :: essa opção define a senha de uma role. Uma senha faz sentido para roles que podem fazer login, entretanto, é permitido definir uma senha para roles que tenham o atributo NOLOGIN. Por omissão, é definida como nula (NULL), esse nulo pode ser definido explicitamente como PASSWORD NULL.

ENCRYPTED | UNENCRYPTED :: essa opção define se a senha será encriptada antes de ser armazenada no catálogo do sistema. O comportamento padrão é definido pelo parâmetro password_encryptation. O padrão é MD5, o que pode ser um problema para alguns clientes antigos que não suportam esse algoritmo.

VALID UNTIL 'estampa_de_tempo' :: permite definir uma data de validade para a senha de uma role. Após essa data essa senha não funciona mais, entretanto, a role ainda é válida para métodos que não dependem de login. Por omissão, as roles não possuem data de validade.

IN ROLE nome_da_role :: lista uma ou mais roles, as quais a nova role que está sendo criada será adicionada como membro. Para adicionar uma role como administrador, é preciso usar o comando GRANT para garantir isso.

IN GROUP nome_da_role :: lista uma ou mais roles que são grupos administrativos, às quais essa nova role será adicionada como membro.

ROLE nome_da_role :: essa opção lista uma ou mais roles já existentes, que são automaticamente adicionadas como membro da nova role que está sendo criada. Isso torna a nova role automaticamente um grupo.

ADMIN nome_da_role :: esta opção é semelhante à anterior, mas as roles inseridas como membros da nova role com essa opção, dão o direito de garantir por herança indireta esse mesmo "papel" para outras roles.

USER nome_da_role :: é uma opção obsoleta que é apenas uma variação da atual cláusula ROLE.

SYSID uid :: é uma opção obsoleta mantida apenas para compatibilidade com sistemas antigos.

Todos os atributos especificados com CREATE ROLE, podem mais tarde ser modificados com ALTER ROLE. Os métodos preferenciais para inserir, ou remover um membro em uma role, são GRANT e REVOKE.

Seja extremamente cuidadoso com as roles que possuem o atributo CREATEROLE. Por exemplo, se uma role não tem permissão para criar um banco de dados, mas tem permissão para criar uma role, ela pode criar uma role que tenha a permissão para criar o banco. Não há uma relação de herança neste caso, assim ela pode criar roles com quaisquer privilégios. O comando de linha no shell chamado de createuser é uma interface para CREATE ROLE.

Exemplos de comandos dados no psql:

> CREATE ROLE admin_db CREATEDB REPLICATION ;
> CREATE ROLE joana WITH ENCRYPTED PASSWORD 'segredo123' ;
> CREATE ROLE joaquim LOGIN ;
> CREATE ROLE beto WITH LOGIN PASSWORD 'segredo123' VALID UNTIL '2015-01-01' ;
> CREATE ROLE estagiario WITH CREATEDB ;


Referências: Manual online do PostgreSQL 9.4 Beta 2.