CREATE ROLE nome [ [ WITH ] opção [ ... ] ] onde opção pode ser: SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | CREATEUSER | NOCREATEUSER | INHERIT | NOINHERIT | LOGIN | NOLOGIN | CONNECTION LIMIT limite_de_conexões | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'senha' | VALID UNTIL 'carimbo_do_tempo' | IN ROLE nome_do_papel [, ...] | IN GROUP nome_do_papel [, ...] | ROLE nome_do_papel [, ...] | ADMIN nome_do_papel [, ...] | USER nome_do_papel [, ...] | SYSID id_usuário
O comando CREATE ROLE adiciona um novo papel (role) ao agrupamento de bancos de dados do PostgreSQL. O papel é uma entidade que pode possuir objetos do banco de dados e possuir privilégios do banco de dados; o papel pode ser considerado como sendo um "usuário", um "grupo", ou ambos, dependendo de como é utilizado. Para obter informações sobre como gerenciar usuários e autenticação deve ser consultado o Capítulo 18 e o Capítulo 20. Para utilizar este comando é necessário possuir o privilégio CREATEROLE, ou ser um superusuário do banco de dados. [1] [2] [3] [4]
Deve ser observado que os papéis são definidos no nível de agrupamento dos bancos de dados e, portanto, são válidos para todos os bancos de dados do agrupamento.
O nome do novo papel.
Estas cláusulas determinam se o novo papel é um "superusuário", o qual pode passar por cima de todas as restrições de acesso dos bancos de dados. O status de superusuário é perigoso, e somente deve ser utilizado quando for realmente necessário. É necessário ser um superusuário para criar um novo superusuário. Se nenhuma destas duas cláusulas for especificada, o padrão é NOSUPERUSER.
Estas cláusulas definem a permissão para o papel criar bancos de dados. Se for especificado CREATEDB, o papel sendo definido poderá criar bancos de dados. Se for especificado NOCREATEDB o papel não poderá criar bancos de dados. Se nenhuma destas duas cláusulas for especificada, o padrão é NOCREATEDB.
Estas cláusulas determinam se o papel terá permissão para criar novos papéis (ou seja, executar o comando CREATE ROLE). Um papel com o privilégio CREATEROLE também pode alterar e remover outros papéis. Se nenhuma destas duas cláusulas for especificada, o padrão é NOCREATEROLE.
Estas cláusulas são formas obsoletas, mas ainda aceitas, das cláusulas SUPERUSER e NOSUPERUSER. Deve ser observado que não são equivalentes a CREATEROLE, como poderia ser esperado!
Estas cláusulas determinam se o papel "herda" os privilégios dos papéis dos quais é membro. Um papel com o atributo INHERIT pode utilizar, automaticamente, todos os privilégios de banco de dados que foram concedidos a todos os papéis dos quais é um membro direto ou indireto. Sem INHERIT, o status de membro de outro papel apenas concede o direito de utilizar o comando SET ROLE especificando este outro papel; os privilégios deste outro papel só se tornarão disponíveis após executar SET ROLE. Se nenhuma destas duas cláusulas for especificada, o padrão é INHERIT.
Estas cláusulas determinam se o papel pode estabelecer uma conexão (log in); ou seja, se o papel pode ser fornecido como nome de autorização inicial da sessão durante a conexão do cliente. Um papel com o atributo LOGIN pode ser considerado como sendo um usuário. Os papéis sem este atributo são úteis para gerenciar privilégios de banco de dados, mas não são usuários no sentido habitual da palavra. Se nenhuma destas duas cláusulas for especificada, o padrão é NOLOGIN, exceto quando CREATE ROLE for chamada através de sua forma alternativa CREATE USER.
Se o papel puder estabelecer uma conexão, esta cláusula especifica quantas conexões simultâneas este papel pode estabelecer. -1 (o padrão) significa sem limite.
Define a senha do papel (A senha só é útil para os papéis que possuem o atributo LOGIN, mesmo assim pode ser definida uma senha para os papéis sem este atributo). Se não se pretende utilizar autenticação por senha, esta opção poderá ser omitida. Se não for especificada nenhuma senha, a senha será definida como nula e a autenticação por senha sempre irá falhar para este usuário. A senha nula pode, opcionalmente, ser escrita explicitamente como PASSWORD NULL.
Estas cláusulas controlam se a senha será armazenada criptografada, ou não, nos catálogos do sistema; Se não for especificada nenhuma destas cláusulas, o comportamento padrão será determinado pelo parâmetro de configuração password_encryption. Se a cadeia de caracteres da senha já estiver criptografada no formato MD5, então a cadeia de caracteres será armazenada como está, independentemente de ser especificado ENCRYPTED ou UNENCRYPTED (porque o sistema não pode descriptografar a cadeia de caracteres criptografada contendo a senha). Esta funcionalidade permite a restauração de senhas criptografadas efetuadas por uma operação de dump/restore.
Deve ser observado que os clientes antigos podem não possuir suporte para o mecanismo de autenticação MD5, necessário para trabalhar com as senhas que são armazenadas criptografadas.
A cláusula VALID UNTIL define uma data e hora após a qual o papel não é mais válido. Se esta cláusula for omitida, a senha será válida para sempre.
A cláusula IN ROLE relaciona um ou mais papéis existentes, aos quais o novo papel será adicionado imediatamente como sendo um novo membro (Deve ser observado que não existe opção para adicionar o novo papel como administrador; para fazer isto deve ser utilizado um comando GRANT em separado).
A cláusula IN GROUP é uma forma obsoleta de IN ROLE.
A cláusula ROLE relaciona um ou mais papéis existentes a serem automaticamente adicionados como membros do novo papel (Isto tem como efeito tornar o novo papel um "grupo").
A cláusula ADMIN é como a cláusula ROLE, mas os papéis especificados são adicionados ao novo papel WITH ADMIN OPTION, dando aos mesmos o direito de permitir que outros papéis se tornem membros deste grupo.
A cláusula USER é uma forma obsoleta da cláusula ROLE.
A cláusula SYSID é ignorada, mas é aceita para manter a compatibilidade com as versões anteriores.
Para mudar os atributos do papel deve ser utilizado o comando ALTER ROLE, e para remover um papel deve ser utilizado o comando DROP ROLE. Todos os atributos especificados em CREATE ROLE poderão ser modificados posteriormente pelo comando ALTER ROLE.
A forma preferida para adicionar e remover membros, em papéis que estão sendo utilizados como grupos, é através dos comandos GRANT e REVOKE.
A cláusula VALID UNTIL define uma data de expiração para a senha apenas, e não para o papel em si. Em particular, a data de expiração não é aplicada ao se conectar utilizando um método de autenticação que não é baseado em senha.
O atributo INHERIT governa a herança dos privilégios que podem ser concedidos (ou seja, os privilégios de acesso aos objetos do banco de dados e ser membro de um papel). Não se aplica aos atributos especiais de papel definidos por CREATE ROLE e ALTER ROLE. Por exemplo, ser membro de um papel com o privilégio CREATEDB não dá imediatamente o direito de criar bancos de dados, mesmo que esteja definido INHERIT; é necessário assumir este papel através do comando SET ROLE antes de criar o banco de dados.
O atributo INHERIT é o padrão por motivo de compatibilidade com as versões anteriores: nas versões anteriores do PostgreSQL, os usuários sempre tinham acesso a todos os privilégios dos grupos dos quais eram membros. Entretanto, NOINHERIT fornece uma correspondência mais próxima da semântica especificada pelo padrão SQL.
Deve ser tomado cuidado com o privilégio CREATEROLE. Não existe o conceito de herança para os privilégios do papel com CREATEROLE. Isto significa que, mesmo que o papel não possua um determinado privilégio, mas tenha permissão para criar outros papéis, poderá facilmente criar um papel com privilégios diferentes do próprio papel (exceto criar papéis com privilégio de superusuário). Por exemplo, o papel "user" possui o privilégio CREATEROLE, mas não o privilégio CREATEDB, mesmo assim pode criar um novo papel com o privilégio CREATEDB. Portanto, os papéis que possuem o privilégio CREATEROLE devem ser considerados como quase papéis superusuários.
O PostgreSQL inclui o aplicativo createuser que possui a mesma funcionalidade do CREATE ROLE (na verdade, chama este comando), mas pode ser executado a partir da linha de comando.
A opção CONNECTION LIMIT é imposta apenas aproximadamente; se duas novas sessões começarem aproximadamente ao mesmo tempo quando restar apenas um "encaixe" de conexão para o papel, será possível que ambas falhem. Além disso, o limite não é imposto aos superusuários.
Deve ser tomado cuidado ao se especificar uma senha não criptografada neste comando. A senha será transmitida para o servidor como texto aberto, e também poderá ficar registrada no histórico de comandos do cliente ou no registro do servidor. O comando createuser transmite a senha criptografada. O aplicativo psql contém o comando \password que poderá ser utilizado para alterar a senha posteriormente com segurança.
Criar um papel que pode estabelecer uma conexão, mas sem fornecer uma senha:
CREATE ROLE joaquim LOGIN;
Criar um papel com uma senha:
CREATE USER manuel WITH PASSWORD 'jw8s0F4';
(O comando CREATE USER é idêntico a CREATE ROLE, exceto por implicar em LOGIN)
Criar um papel com uma senha válida até o fim de 2004. Após o primeiro segundo de 2005 a senha não será mais válida.
CREATE ROLE manuel WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01';
Criar um papel que pode criar bancos de dados e gerenciar papéis:
CREATE ROLE admin WITH CREATEDB CREATEROLE;
O comando CREATE ROLE faz parte do padrão SQL, mas o padrão requer apenas a sintaxe
CREATE ROLE nome [ WITH ADMIN nome_do_papel ]
Vários administradores iniciais, e todas as demais opções do comando CREATE ROLE, são extensões do PostgreSQL.
O padrão SQL define os conceitos de usuário e de papel, mas considera-os como sendo conceitos distintos, e deixa para a implementação de cada sistema de banco de dados a especificação de todos os comandos para definir usuários. No PostgreSQL foi decidido pela unificação de usuários e papéis em um único tipo de entidade. Portanto, os papéis possuem muito mais atributos opcionais do que no padrão.
Fica mais próximo do comportamento especificado pelo padrão SQL quando se dá aos usuários o atributo NOINHERIT, e aos papéis o atributo INHERIT.
| [1] |
Oracle — Introdução aos papéis — O gerenciamento e controle dos privilégios fica mais fácil quando se utilizam papéis (roles), que são grupos com nome de privilégios relacionados que são concedidos, como um grupo, aos usuários e outros grupos. No banco de dados cada nome de papel deve ser único, diferente dos nomes de todos os usuários e de todos os papéis. Diferentemente dos objetos do esquema, os papéis não estão contidos em nenhum esquema. Portanto, o usuário que criou o papel pode ser removido sem afetar o papel. Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 (N. do T.) |
| [2] |
Oracle — Para criar um papel, que é um conjunto de privilégios que pode ser concedido a usuários ou a outros papéis, é utilizado o comando CREATE ROLE. Os papéis podem ser utilizados para administrar os privilégios do banco de dados. Podem ser adicionados privilégios aos papéis, e depois ser concedido o papel para um usuário. O usuário poderá, então, ativar o papel para exercer os privilégios concedidos pelo papel. O papel possui todos os privilégios concedidos para o papel, e todos os privilégios dos outros papéis concedidos a este papel. O novo papel se encontra inicialmente vazio. Os privilégios para o papel são adicionados através do comando GRANT. Oracle® Database SQL Reference 10g Release 1 (10.1) Part Number B10759-01 (N. do T.) |
| [3] |
SQL Server — O comando CREATE ROLE cria um novo papel de banco de dados no banco de dados corrente. Os papéis são securables no nível de banco de dados. Após o papel ser criado, as permissões no nível de banco de dados são configuradas utilizando os comandos GRANT, DENY e REVOKE. Para adicionar membros a um papel no nível de banco de dados é utilizado o procedimento armazenado sp_addrolemember. SQL Server 2005 Books Online — CREATE ROLE (Transact-SQL) (N. do T.) |
| [4] |
SQL Server — Todos os objetos de um banco de dados estão localizados em esquemas. Todo esquema pertence a papéis (roles) em vez de a usuários individuais, permitindo que múltiplos usuários administrem objetos de banco de dados. Isso resolve uma questão das primeiras versões do SQL Server, em que os usuários não podiam ser excluídos de um banco de dados sem repassar a posse de cada objeto que possuíam. Agora você só precisa alterar a posse do esquema, não de cada objeto. Microsoft SQL Server 2005™ — Guia de Bolso do Administrador — William R. Stanek, pág. 235 (N. do T.) |
