Atribuição e remoção de direitos. Configurando permissões comando grant Usando visualizações para filtrar privilégios

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) TO user_name "senha"] [, user_name ...] ] ] ] ] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) FROM user_name [, user_name ...]

GRANT está incluído no MySQL versão 3.22.11 e superior. Nas versões anteriores do MySQL, a instrução GRANT não faz nada.

Os comandos GRANT e REVOKE permitem que administradores de sistema criem usuários MySQL e concedam ou revoguem direitos a usuários em quatro níveis de privilégio:

Nível global Os privilégios globais se aplicam a todos os bancos de dados no servidor especificado. Esses privilégios são armazenados na tabela mysql.user. Nível de banco de dados Os privilégios do banco de dados se aplicam a todas as tabelas do banco de dados especificado. Esses privilégios são armazenados nas tabelas mysql.db e mysql.host. Nível da tabela Os privilégios de tabela se aplicam a todas as colunas da tabela especificada. Esses privilégios são armazenados na tabela mysql.tables_priv. Nível da coluna Os privilégios de coluna aplicam-se a colunas individuais na tabela especificada. Esses privilégios são armazenados na tabela mysql.columns_priv.

Se privilégios forem concedidos a um usuário que não existe, esse usuário será criado. Para exemplos do comando GRANT, consulte a seção 4.3.5 Adicionando novos usuários ao MySQL.

A tabela mostra uma lista de valores possíveis para o parâmetro priv_type para as instruções GRANT e REVOKE:

TODOS	Define todos os privilégios simples, exceto COM GRANT OPTION
ALTERAR	Permite o uso de ALTER TABLE
CRIAR	Permite o uso de CREATE TABLE
CRIAR TABELAS TEMPORÁRIAS	Permite o uso de CREATE TEMPORARY TABLE
EXCLUIR	Permite o uso de DELETE
DERRUBAR	Permite o uso de DROP TABLE.
EXECUTAR	Permite ao usuário executar procedimentos armazenados (para MySQL 5.0)
ARQUIVO	Permite o uso de SELECT ... INTO OUTFILE e LOAD DATA INFILE .
ÍNDICE	Permite o uso de CREATE INDEX e DROPÍNDICE
INSERIR	Permite o uso de INSERT
BLOQUEAR TABELAS	Permite o uso de LOCK TABLES em tabelas que possuem o privilégio SELECT.
PROCESSO	Permite o uso de SHOW FULL PROCESSLIST
REFERÊNCIAS	Reservado para uso futuro
RECARREGAR	Permite o uso de FLUSH
CLIENTE DE REPLICAÇÃO	Concede ao usuário o direito de consultar a localização dos servidores mestre e escravo.
ESCRAVO DE REPLICAÇÃO	Necessário para servidores escravos durante a replicação (para leitura de informações dos logs binários do servidor principal).
SELECIONAR	Permite o uso de SELECT
MOSTRAR BANCOS DE DADOS	SHOW DATABASES Lista todos os bancos de dados.
DESLIGAR	Permite o uso do desligamento do mysqladmin
SUPER	Permite que você estabeleça uma conexão (uma vez), mesmo se max_connections for atingido, e execute os comandos CHANGE MASTER , KILL thread , mysqladmin debug , PURGE MASTER LOGS e SET GLOBAL
ATUALIZAR	Permite o uso de UPDATE
USO	Sinônimo de ``sem privilégios''.

O valor USAGE pode ser especificado se você precisar criar um usuário sem privilégios.

Os privilégios CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION ..., SHOW DATABASES e SUPER são novos na versão 4.0.2. Para aproveitar esses novos privilégios após atualizar para a versão 4.0.2, você deve executar o script mysql_fix_privilege_tables.

Em versões mais antigas do MySQL, o privilégio PROCESS concede os mesmos direitos que o novo privilégio SUPER.

Para revogar os privilégios de um usuário concedidos pelo comando GRANT, use o valor priv_type na GRANT OPTION:

Mysql> REVOKE GRANT OPTION ON...FROM...;

Os únicos valores priv_type que podem ser especificados para uma tabela são: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, IDEX e ALTER.

Os únicos valores priv_type que podem ser especificados para uma coluna (ao usar o operador column_list) são SELECT , INSERT e UPDATE .

Os privilégios globais podem ser definidos usando a sintaxe ON *.* e os privilégios do banco de dados podem ser definidos usando a sintaxe ON db_name.*. Se você especificar ON * enquanto o banco de dados atual estiver aberto, os privilégios serão definidos para esse banco de dados. ( Aviso: se você especificar ON * quando ausência o banco de dados atual estiver aberto, isso afetará os privilégios globais!)

Para poder definir direitos para usuários em computadores específicos, o MySQL oferece a capacidade de especificar o nome do usuário (user_name) no formulário. Se você precisar especificar uma string de usuário que contenha caracteres especiais (como `-") ou uma string de host que contenha caracteres especiais ou curinga (como `%"), você poderá colocar o nome computador remoto ou usuário entre aspas (por exemplo, "test-user"@"test-hostname").

Você também pode incluir curingas no nome do computador remoto. Por exemplo, "%.loc.gov" refere-se ao usuário de todos os computadores remotos no domínio loc.gov e "144.155.166.%" refere-se ao usuário de todos os computadores remotos na sub-rede classe C 144.155.166.

O formulário simples user é sinônimo de "%" .

MySQL não suporta curingas em nomes de usuário. Usuários anônimos são definidos inserindo registros User="" na tabela mysql.user ou criando um usuário com nome vazio usando o comando GRANT.

Observação: Se usuários anônimos tiverem permissão para se conectar ao servidor MySQL, você também deverá conceder privilégios a todos os usuários locais como , porque caso contrário, quando um usuário tentar fazer login no MySQL a partir do computador local, a tabela mysql.user usará o usuário anônimo Conecte-se!

Para verificar se isso acontece no seu computador, execute a seguinte consulta:

Mysql> SELECT Host,Usuário FROM mysql.user WHERE Usuário="";

Atualmente, o comando GRANT suporta nomes de computadores remotos, tabelas, bancos de dados e colunas de até 60 caracteres. O nome de usuário não deve conter mais de 16 caracteres.

Os privilégios para uma tabela ou coluna são formados usando o operador lógico OR a partir dos privilégios em cada um dos quatro níveis. Por exemplo, se a tabela mysql.user indicar que o usuário possui o privilégio SELECT global, esse privilégio não será revogado no nível do banco de dados, tabela ou coluna.

Os privilégios para uma coluna podem ser calculados da seguinte forma:

Privilégios globais OU (privilégios de banco de dados E privilégios de computador remoto) OU privilégios de tabela OU privilégios de coluna

Na maioria dos casos, os direitos do usuário são definidos em apenas um nível de privilégio, portanto este procedimento geralmente não é tão complexo como descrito acima. informação detalhada A sequência de ações para verificação de privilégios é apresentada na seção 4.2 Questões gerais de segurança e sistema de privilégios de acesso MySQL.

Se privilégios forem concedidos a uma combinação usuário/remoto que não esteja na tabela mysql.user, uma entrada será adicionada à tabela mysql.user e permanecerá na tabela até ser excluída usando o comando DELETE. Em outras palavras, o comando GRANT pode criar registros de usuário na tabela, mas o comando REVOKE não pode excluí-los. Isso deve ser feito usando o comando DELETE.

Se você tiver privilégios de banco de dados, uma entrada será criada na tabela mysql.db, se necessário. Esta entrada é excluída depois que todos os privilégios deste banco de dados são removidos com o comando REVOKE.

Se um usuário não tiver privilégios em uma tabela, a tabela não será exibida quando o usuário solicitar uma lista de tabelas (por exemplo, usando a instrução SHOW TABLES).

A instrução WITH GRANT OPTION dá ao usuário a capacidade de conceder a outros usuários quaisquer privilégios que ele próprio possua em um nível de privilégio especificado. Deve-se ter cuidado ao conceder o privilégio GRANT, pois dois usuários com privilégios diferentes podem combinar seus privilégios!

As opções MAX_QUERIES_PER_HOUR # , MAX_UPDATES_PER_HOUR # e MAX_CONNECTIONS_PER_HOUR # são novas no MySQL versão 4.0.2. Essas configurações limitam o número de solicitações, atualizações e logins que um usuário pode fazer em uma hora. Se definido como 0 (o padrão), significa que não há restrições para este usuário. Consulte a seção.

Você não pode conceder a outro usuário um privilégio que você não possui. O privilégio GRANT permite conceder apenas os privilégios que você possui.

Observe que se um usuário receber o privilégio GRANT em um determinado nível de privilégio, todos os privilégios que esse usuário já possui (ou que serão atribuídos no futuro!) nesse nível também poderão ser atribuídos a esse usuário. Vamos supor que um usuário recebeu o privilégio INSERT em um banco de dados. Se você conceder o privilégio SELECT no banco de dados e especificar WITH GRANT OPTION, o usuário poderá conceder não apenas o privilégio SELECT, mas também o privilégio INSERT. Se você conceder ao usuário o privilégio UPDATE no banco de dados, o usuário poderá emitir INSERT, SELECT e UPDATE.

Os privilégios ALTER não devem ser atribuídos a usuários regulares. Isso dá ao usuário a capacidade de quebrar o sistema de privilégios renomeando tabelas!

Por favor, note que se os privilégios de tabela ou coluna forem usados ​​para apenas um usuário, o servidor verifica os privilégios de tabela e coluna para todos os usuários e isso torna o MySQL um pouco mais lento.

Quando o mysqld inicia, todos os privilégios são lidos na memória. Os privilégios de banco de dados, tabelas e colunas entram em vigor imediatamente, enquanto os privilégios em nível de usuário entram em vigor na próxima vez que o usuário se conectar. As alterações nas tabelas de atribuição de privilégios feitas utilizando os comandos GRANT e REVOKE são processadas imediatamente pelo servidor. Se você modificar as tabelas de atribuição de privilégios manualmente (usando INSERT , UPDATE , etc.), você deverá executar a instrução FLUSH PRIVILEGES ou mysqladmin flush-privilege s para instruir o servidor a recarregar as tabelas de atribuição de privilégios. Consulte a seção 4.3.3 Quando as alterações de privilégio entram em vigor.

As diferenças mais significativas entre as versões ANSI SQL e MySQL do comando GRANT são as seguintes:

• No MySQL, os privilégios são atribuídos à combinação de nome de usuário + computador remoto, não apenas ao nome de usuário.
• ANSI SQL não possui privilégios globais ou em nível de banco de dados, e ANSI SQL não oferece suporte a todos os tipos de privilégios do MySQL. O MySQL, por outro lado, não suporta os privilégios ANSI SQL TRIGGER, EXECUTE ou UNDER.
• A estrutura de privilégios ANSI SQL é hierárquica. Se você excluir um usuário, todos os privilégios atribuídos a esse usuário serão revogados. No MySQL, os privilégios atribuídos não são revogados automaticamente; você mesmo deve removê-los, se necessário.
• No MySQL, um usuário pode INSERT uma tabela se tiver privilégio INSERT em apenas algumas colunas dessa tabela. As colunas que não possuem o privilégio INSERT serão definidas com seus valores padrão. ANSI SQL requer privilégio INSERT em todas as colunas.
• Quando você elimina uma tabela no ANSI SQL, todos os privilégios dessa tabela serão revogados. Se você revogar um privilégio no ANSI SQL, todos os privilégios atribuídos com base nesse privilégio também serão revogados. No MySQL, os privilégios só podem ser removidos usando o comando REVOKE ou alterando as tabelas de atribuição de privilégios do MySQL.

Para obter uma descrição do uso de REQUIRE, consulte a seção 4.3.9 Usando conexões seguras.

Comentários do usuário

Postado por Frank Wortner

[Excluir] [Editar]

Não tive problemas com ld. DEC (Compaq) pode
corrigi ld em um kit de patch. Você pode querer
instale o kit de patch mais recente para o seu Digital Unix
(Tru64 Unix) antes de construir o MySQL. Conjuntos de patches
estão disponíveis em
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Postado por no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Para instalações de origem, estas instruções referem-se à estrutura de diretórios, presumindo que "usr/local" foi usado (padrão) com o configure. Mas as instruções da página anterior (para compilação/instalação) sugerem que você use:

./configure --prefix=/usr/local/mysql

Para ser consistente (e isso está me causando alguns problemas com Perl, portanto não é puramente semântico), as instruções nesta página devem presumir que /usr/local/mysql foi especificado como o diretório de instalação com configure.

Postado por Linda Wright no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Este é provavelmente o mais importante e menos importante
seções apreciadas de todo o mySQL
documentação para usuários iniciantes do MySQL. NA MINHA HUMILDE OPINIÃO,
lendo esta página em conjunto com
http://www.mysql.com/doc/P/r/Privileges.html é um
obrigatório para planejar qualquer sistema de banco de dados seguro
de qualquer sofisticação real.

Postado por Christopher Raymond no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Estou tentando instalar o MySQL no OS X Public Beta. Quando executo o script mysql_install_db, recebo uma mensagem de erro:

Dyld: ./bin/mysqld não pode abrir a biblioteca: /usr/lib/libpthread.A.dylib (esse arquivo ou diretório não existe, errno = 2)
Falha na instalação das tabelas de concessão!

Presumo que o script esteja procurando um diretório que não existe porque a Apple tem uma estrutura de nomenclatura de diretório um pouco diferente.Talvez esse script precise ser modificado para a distribuição do OS X.

Alguém pode ajudar?

Postado por Mark Zieg no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Seria bom se houvesse uma opção para registrar conexões, mas não consultas.

Postado por Bennett Haselton no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Se você estiver logado como usuário root do mysql, sem um banco de dados atual selecionado, e tentar
conceda todos os privilégios a um usuário com o comando:

CONCEDER TODOS OS PRIVILÉGIOS EM * PARA bhaselto

Então o RELOAD, SHUTDOWN, PROCESS, FILE e GRANT não serão concedidos, como pode ser
verificado verificando a tabela "user" do banco de dados "mysql". (Isso provavelmente é intencional,
já que esses privilégios podem tornar um usuário "muito poderoso".)

Postado por DC Hill no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

NOTA: Se você concedeu privilégios a um usuário em um banco de dados específico, ou em qualquer nível inferior a esse, invocando "REVOKE ALL ON *.* FROM ;" NÃO revogará privilégios nesses níveis. O *.* na declaração acima significa "global", não "todas as tabelas (individuais) em todos os bancos de dados (individuais). Essa declaração SÓ revogará privilégios globais, conforme armazenados na tabela mysql.user. Você DEVE revogar qualquer mais específico privilégios da mesma maneira como foram concedidos, se você deseja que eles sejam removidos das tabelas de privilégios. (ou seja, - GRANT ALL ON foo.* TO ; => REVOKE ALL ON foo.* FROM ;) Espero que isso salve alguns dos você um pouco de tempo e frustração.

Postado por Cris Perdue no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

"Se você tiver o privilégio de processo, poderá ver
Todos os tópicos.
Caso contrário, você poderá ver apenas seus próprios tópicos."

Postado pelos fóruns do FreeBSD no sábado, 16 de fevereiro de 2002, às 22h21

[Excluir] [Editar]

Você pode usar a ferramenta baseada na web phpMyAdmin para fazer muitas coisas
das funções administrativas do MySQL. href="http://www.freebsdforums.org"
> Fóruns do FreeBSD

Postado por na segunda-feira, 25 de fevereiro de 2002, às 6h03

[Excluir] [Editar]

Verificado no MySQL 3.23.36 no Red Hat Linux 7.1:
Observe que se você digitar
use ac_c;
conceder seleção em * para ;
você terá acesso a qualquer
banco de dados correspondente a "a_c", onde o sublinhado é um
curinga. (Raramente é um problema, suponho).
Retificar com
atualize mysql.db set db="a\_c" onde db="a_c";

Postado por jan behrens na terça-feira, 9 de julho de 2002, às 1h31

[Excluir] [Editar]

o bug mencionado de DAN ELIN em x.x.41 é
aparentemente ainda válido em x.x.51, não consigo fazer login em um
banco de dados após conceder privilégios e receber um
senha para um novo usuário (sim, eu liberei
privilégios)...........somente acesso root é possível

Postado por Dan Egli na quinta-feira, 4 de abril de 2002, às 20h33

[Excluir] [Editar]

Parece haver um bug no 3.23.41 usando Grant.
Somente root pode acessar o banco de dados mysql, mesmo
depois de usar Grant para conceder privilégios em qualquer coisa
banco de dados/tabela/coluna/ect.. você sempre obtém
permissão negada, independentemente.

Postado por Lars Aronsson no sábado, 8 de junho de 2002, às 11h16

["%". Quando tento excluí-los, recebo informações de um banco de dados certo, mas sem privilégios globais, o Privilégio CREATE TEMPORARY TABLE nesse banco de dados é negado. Você tem que dar global CREATE __and__ global CRIAR TABELAS TEMPORÁRIAS para o usuário. IOW: GRANT CREATE, CRIAR TABELAS TEMPORÁRIAS EM *.* PARA ; Escusado será dizer que isso afeta gravemente a segurança. Postado por domingo, 25 de agosto de 2002, às 9h17 [Excluir] [Editar] Arquivos temporários são uma ótima ideia, mas mesmo com Direitos Criar e Criar Arquivo Temporário no arquivo de usuário (direitos globais), ele ainda não funciona. Isso parece estar mal projetado. Postado por Brad Bulger na segunda-feira, 2 de setembro de 2002, às 4h09 [Excluir] [Editar] Deve-se notar que apenas COM OPÇÃO DE CONCESSÃO permite que o usuário passe privilégios para usuários que já existe. A criação automática de usuário registros não aplicar - você recebe um erro dizendo que o usuário com o privilégio GRANT OPTION faça não tem acesso ao banco de dados "mysql". Isso é provavelmente é uma coisa boa, mas precisa ser documentada. Postado por Michael Babcock na sexta-feira, 8 de novembro de 2002, às 13h [Excluir] [Editar] SHOW MASTER STATUS requer privilégios PROCESS. Outras combinações estranhas devem ser documentadas. Postado por Dee Kintaudi na quinta-feira, 21 de novembro de 2002, às 12h42 [Excluir] [Editar] Ok, eu tenho uma pergunta e um problema com o Mysql e senhas:). Eu tentei usar várias das opções e a maioria deles não funcionou. No entanto, um soloution funcionou e eu testei duas vezes e era sólido. É claro que perdi o pedacinho de papel que escrevi e não consigo encontrar isso solução em qualquer lugar, como se ela não existisse ou talvez eu imaginei isso. A solução que funcionou para mim, antes de perder o pedacinho de papel em que anotei vai algo assim..... Insira dentro de usuário raiz Senha "minha senha" e depois algo com "Y", "Y", "Y", (cerca de uma dúzia ou 15 vezes ou mais) No entanto, não consigo encontrar esta solução em nenhum lugar. Alguém me ajude aqui? Eu acho que seria tão bom se eles simplesmente colocassem isso em toda a sua documentação, em vez de tentar Esconde. Acho que isso resolveria muitos problemas. Apenas coloque senha = "Y", "Y", "Y", é como se eles tivessem vergonha disso ou alguma coisa. Postado por AJIT DIXIT na segunda-feira, 25 de novembro de 2002, às 6h56 [Excluir] [Editar] Quando trabalho na atualização de várias tabelas com o usuário root Funciona bem Quando trabalho com usuário não root, recebo um erro Sql: atualizar Estoquistas, áreas definidas a_nm = aname onde acd = área

Neste capítulo, você aprenderá como trabalhar com privilégios. Conforme discutido no Capítulo 2, o SQL é normalmente usado em ambientes que exigem reconhecimento de usuários e distinção entre diferentes usuários de sistemas. Em geral, os próprios administradores de banco de dados criam usuários e concedem-lhes privilégios. Por outro lado, os próprios usuários que criam tabelas têm direitos para gerenciá-las. Privilégios são o que determinam se um usuário especificado pode executar um determinado comando. Existem vários tipos de privilégios correspondentes a vários tipos de operações. Os privilégios são concedidos e revogados usando dois comandos SQL: - GRANT e REVOKE. Este capítulo mostrará como esses comandos são usados.

USUÁRIOS

Cada usuário em um ambiente SQL possui um nome ou número de identificação especial. A terminologia é diferente em todos os lugares, mas optamos (seguindo o ANSI) referir-se a ela ou ao número como Identificador de Acesso (ID). Um comando enviado ao banco de dados está associado a um usuário específico; ou de outra forma, um Identificador de Acesso especial. No que se refere a um banco de dados SQL, o ID de permissão é o nome de usuário, e o SQL pode usar a palavra-chave especial USER, que se refere ao ID de acesso associado ao comando atual. O comando é interpretado e permitido (ou negado) com base nas informações associadas ao ID de acesso do usuário que emite o comando.

CADASTRO

Em sistemas com numerosos usuários, existe algum tipo de procedimento de login que o usuário deve realizar para obter acesso ao sistema do computador. Este procedimento determina qual ID de acesso será associado ao usuário atual. Normalmente, cada pessoa que utiliza o banco de dados deve ter seu próprio ID de acesso e após o registro torna-se um usuário válido. No entanto, muitas vezes os utilizadores com muitas tarefas podem ser registados sob diferentes IDs de acesso ou, inversamente, um ID de acesso pode ser utilizado por vários utilizadores. Do ponto de vista SQL, não há diferença entre esses dois casos; trata o usuário simplesmente como seu ID de acesso. O banco de dados SQL pode usar seu próprio procedimento de login ou pode permitir outro programa, como sistema operacional(o principal programa executado no seu computador), processe o arquivo de registro e obtenha o ID de acesso deste programa. De uma forma ou de outra, o SQL terá um ID de acesso para associar às suas ações, e a palavra-chave USER será relevante para você.

FORNECENDO PRIVILÉGIOS

Cada usuário em um banco de dados SQL possui um conjunto de privilégios. Isto é o que o usuário pode fazer (talvez seja um arquivo de log, que pode ser considerado um privilégio mínimo). Esses privilégios podem mudar com o tempo – novos são adicionados, os antigos são removidos. Alguns desses privilégios são definidos em ANSI SQL, mas há privilégios adicionais que também são necessários. Os privilégios SQL definidos pela ANSI não são suficientes na maioria das situações da vida real. Por outro lado, os tipos de privilégios necessários podem variar de acordo com o tipo de sistema que você está usando – para o qual a ANSI não faz recomendações. Privilégios que não fazem parte do padrão SQL podem usar sintaxe semelhante e não totalmente consistente com o padrão.

PRIVILÉGIOS PADRÃO

Os privilégios SQL definidos pelo ANSI são privilégios de objeto. Isso significa que o usuário tem o privilégio de executar um determinado comando apenas em um objeto específico do banco de dados. Obviamente, os privilégios devem distinguir entre esses objetos, mas um sistema de privilégios baseado apenas nos privilégios de um objeto não pode atender a tudo o que o SQL precisa, como veremos mais adiante neste capítulo. Os privilégios de um objeto estão associados a usuários e tabelas. Ou seja, o privilégio é concedido a um usuário específico em uma tabela específica, ou tabela ou visualização subjacente. Você deve lembrar que o usuário que criou a tabela (de qualquer tipo) é o proprietário desta tabela.

Isso significa que o usuário possui todos os privilégios nesta tabela e pode transferir privilégios para outros usuários nesta tabela. Privilégios que podem ser atribuídos a um usuário:

SELECT Um usuário com este privilégio pode executar consultas na tabela.

INSERT Um usuário com este privilégio pode emitir um comando INSERT em uma tabela.

UPDATE Um usuário com este privilégio pode emitir um comando UPDATE em uma tabela. Você pode restringir esse privilégio a colunas específicas da tabela.

DELETE Um usuário com este privilégio pode emitir um comando DELETE em uma tabela.

REFERÊNCIAS Um usuário com este privilégio pode definir uma chave estrangeira que utilize uma ou mais colunas desta tabela como chave pai. Você pode restringir esse privilégio a determinadas colunas. (Consulte o Capítulo 19 para obter detalhes sobre chave estrangeira e chave pai.)

Além disso, você encontrará privilégios de objeto não padrão, como INDEX, que dá o direito de criar um índice em uma tabela, SYNONYM, que dá o direito de criar um sinônimo para um objeto, que será explicado no Capítulo 23, e ALTER, que dá o direito de executar o comando ALTER TABLE em uma tabela. O mecanismo SQL atribui esses privilégios aos usuários usando o comando GRANT.

EQUIPE DE CONCESSÃO

Vamos supor que a usuária Diane possua uma tabela Clientes e queira permitir que o usuário Adrian a consulte. Diane deve então digitar o seguinte comando:

INSERÇÃO DE CONCESSÃO SOBRE Vendedores PARA Diane;

Agora Adrian pode executar consultas na tabela Clientes. Sem outros privilégios, ele só pode selecionar valores; mas não pode realizar nenhuma ação que possa afetar os valores da tabela Clientes (incluindo o uso da tabela Clientes como tabela pai da chave estrangeira, o que limita as alterações que podem ser feitas no valor da tabela Clientes).

Quando o SQL recebe um comando GRANT, ele verifica os privilégios do usuário que emite o comando para determinar se o comando GRANT é válido. Adrian não pode emitir este comando sozinho. Ela também não pode conceder permissão SELECT a outro usuário: a tabela ainda pertence a Diane (mostraremos mais tarde como Diane pode conceder permissão SELECT a Adrian para outros usuários).

A sintaxe é a mesma para conceder outros privilégios. Se Adrian for o proprietário da tabela Sellers, ele poderá permitir que Diane insira linhas nela usando a seguinte cláusula

INSERÇÃO DE CONCESSÃO SOBRE Vendedores PARA Diane; Diane agora tem o direito de colocar um novo vendedor na mesa.

GRUPOS DE PRIVILÉGIOS, GRUPOS DE USUÁRIOS

Você não deve se limitar a conceder um único privilégio a um usuário individual com o comando GRANT. Listas de privilégios ou usuários separados por vírgulas são perfeitamente aceitáveis. Stephen pode fornecer SELECT e INSERT na tabela Order para Adrian

GRANT SELECT, INSERT ON Orders PARA Adrian; ou para Adrian e Diane GRANT SELECT, INSERT ON Orders TO Adrian, Diane;

Quando privilégios e usuários são listados dessa forma, toda a lista de privilégios é concedida a todos os usuários especificados. Na interpretação ANSI estrita, você não pode conceder privilégios em muitas tabelas ao mesmo tempo com um único comando, mas algumas implementações podem relaxar essa restrição, permitindo especificar múltiplas tabelas, separadas por vírgulas, para que toda a lista de privilégios possa ser concedida para todos. tabelas especificadas.

LIMITANDO PRIVILÉGIOS EM COLUNAS ESPECÍFICAS

Todos os privilégios de objeto utilizam a mesma sintaxe, exceto os comandos UPDATE e REGERNCES, que não requerem nomes de colunas. O privilégio UPDATE pode ser concedido como outros privilégios:

CONCESSE ATUALIZAÇÃO SOBRE Vendedores PARA Diane;

Este comando permitirá que Diane altere os valores em uma ou todas as colunas da tabela Fornecedores. No entanto, se Adrian quiser impedir que Diane altere, por exemplo, comissões, ele poderá entrar

CONCESSE ATUALIZAÇÃO (comm) SOBRE Vendedores PARA Diane;

Em outras palavras, basta especificar a coluna específica na qual o privilégio UPDATE deve ser aplicado, entre parênteses após o nome da tabela. Os nomes de múltiplas colunas da tabela podem ser especificados em qualquer ordem, separados por vírgulas:

CONCESSE ATUALIZAÇÃO (cidade, comm) SOBRE Vendedores PARA Diane;

REFERÊNCIAS segue a mesma regra. Quando você concede o privilégio REFERENCES a outro usuário, ele poderá criar chaves estrangeiras que fazem referência a colunas em sua tabela como chaves pai. Assim como UPDATE, o privilégio REFERENCES pode ser especificado como uma lista de uma ou mais colunas para as quais esse privilégio é restrito. Por exemplo, Diane poderia conceder a Stephen o direito de usar a tabela Customer como tabela-chave pai com o seguinte comando:

REFERÊNCIAS DE CONCESSÃO (cname, cnum) SOBRE Clientes PARA Stephen; Este comando dá a Stephen o direito de usar as colunas cnum e cname como chaves pai para quaisquer chaves estrangeiras em suas tabelas. Stephen pode controlar como isso é feito. Ele pode definir (cname, cnum) ou, no nosso caso, (cnum, cname), como uma chave pai de duas colunas correspondida por uma chave estrangeira para duas colunas em uma de suas próprias tabelas. Ou pode criar chaves estrangeiras separadas para se referir ao género individualmente, garantindo assim que Diane tenha uma chave-mãe atribuída a ela (ver Capítulo 19).

Sem restrições aos números de chave estrangeira, deve basear-se nessas chaves-pai, e as chaves-pai de diferentes chaves estrangeiras devem poder se sobrepor.

Tal como acontece com o privilégio UPDATE, você pode excluir uma lista de colunas e assim permitir que todas as colunas sejam usadas como chaves pai. Adrian pode conceder a Diane o direito de fazer isso com o seguinte comando:

CONCESSE REFERÊNCIAS SOBRE Vendedores PARA Diane;

Naturalmente, o privilégio só poderá ser utilizado em colunas que possuam as restrições exigidas pelas chaves pai.

USANDO TODOS OS ARGUMENTOS PÚBLICOS

SQL suporta dois argumentos para o comando GRANT que possuem um significado especial: ALL PRIVILEGES ou simplesmente ALL e PUBLIC. ALL é usado em vez de nomes de privilégios no comando GRANT para conceder todos os privilégios em uma tabela. Por exemplo, Diane poderia conceder a Stephen todo o conjunto de privilégios na tabela Clientes com o seguinte comando:

CONCESSE REFERÊNCIAS SOBRE Vendedores PARA Diane;

(Os privilégios UPDATE e REFERENCES se aplicam naturalmente a todas as colunas.) Aqui está outra maneira de dizer a mesma coisa:

CONCESSE TODOS OS CLIENTES PARA Stephen;

PUBLIC é mais um tipo de argumento abrangente do que um privilégio de usuário. Quando você concede privilégios de publicação, todos os usuários os recebem automaticamente. Na maioria das vezes, isso é usado para o privilégio SELECT em determinadas tabelas ou visualizações subjacentes que você deseja disponibilizar para qualquer usuário. Para permitir que qualquer usuário veja a tabela Pedidos, você poderia, por exemplo, inserir o seguinte:

GRANT SELECT EM PEDIDOS AO PÚBLICO;

É claro que você pode conceder algum ou todos os privilégios à sociedade, mas isso provavelmente não é aconselhável. Todos os privilégios, exceto SELECT, permitem ao usuário alterar (ou, no caso de REFERÊNCIAS, restringir) o conteúdo da tabela. Permitir que todos os usuários alterem o conteúdo de suas tabelas causará um problema.

Mesmo que você tenha uma empresa pequena e todos os seus usuários atuais sejam capazes de executar comandos de modificação em uma determinada tabela, seria melhor conceder privilégios a cada usuário individualmente do que conceder os mesmos privilégios a todos. PUBLIC não se limita a transferi-lo apenas para usuários atuais. Qualquer Novo usuário adicionado ao seu sistema receberá automaticamente todos os privilégios atribuídos anteriormente a todos, portanto, se você deseja limitar o acesso à tabela a todos, agora ou no futuro, é melhor conceder privilégios diferentes de SELECT para usuários individuais.

CONCESSÃO DE PRIVILÉGIOS USANDO COM GRANT OPTION

Às vezes, o criador de uma tabela deseja que outros usuários possam obter privilégios em sua tabela. Isso normalmente é feito em sistemas onde uma ou mais pessoas criam várias (ou todas) as tabelas base em um banco de dados e depois delegam a responsabilidade por elas àqueles que realmente trabalharão com elas. SQL permite que você faça isso usando a cláusula WITH GRANT OPTION. Se Diane quisesse que Adrian pudesse conceder o privilégio SELECT na tabela Clientes a outros usuários, ela concederia a ele o privilégio SELECT usando a cláusula WITH GRANT OPTION:

GRANT SELECT ON Clientes PARA Adrian COM OPÇÃO DE GRANT; Adrian adquiriu então o direito de transferir o privilégio SELECT para terceiros; pode emitir o comando GRANT SELECT ON Diane.Customers TO Stephen; ou mesmo GRANT SELECT ON Diane.Clientes PARA Stephen COM GRANT OPTION; Um usuário com GRANT OPTION em um privilégio específico em uma determinada tabela pode, por sua vez, conceder esse privilégio na mesma tabela, com ou sem GRANT OPTION, a qualquer outro usuário. Isto não altera a propriedade da tabela em si; como antes, a tabela pertence ao seu criador. (Portanto, os usuários concedidos devem prefixar o ID de acesso do proprietário ao fazer referência a essas tabelas. O próximo capítulo mostrará esse método.) Um usuário que usa a GRANT OPTION em todos os privilégios de uma determinada tabela terá autoridade total nessa tabela.

CANCELAMENTO DE PRIVILÉGIOS

Assim como ANSI fornece o comando CREATE TABLE para criar uma tabela, em vez do comando DROP TABLE para se livrar dela, o comando GRANT permite conceder privilégios aos usuários sem fornecer uma maneira de recuperá-los. A necessidade de remover privilégios se resume ao comando REVOKE, que na verdade é uma ferramenta padrão com uma forma de entrada bastante clara. A sintaxe do comando REVOKE é semelhante a GRANT, mas tem o significado oposto. Para remover o privilégio INSERT de Adrian na tabela Pedido, você pode inserir

REVOKE INSERT ON Orders FROM Adrian;

O uso de listas de privilégios e usuários é permitido aqui como em GRANT, então você pode inserir o seguinte comando:

REVOKE INSERT, DELETE ON Clientes DE Adrian, Stephen; No entanto, há alguma ambiguidade aqui. Quem tem o direito de revogar privilégios? Quando um usuário com direito de transferir privilégios para outros perde esse direito? Os usuários a quem ele concedeu esses privilégios também os perderão? Como este não é um recurso padrão, não há respostas oficiais para essas perguntas, mas a abordagem mais comum é esta: * Os privilégios são revogados pelo usuário que os concedeu, e a revogação ocorrerá em cascata, ou seja, será automaticamente propagada para todos os usuários que receberam o privilégio dele.

USANDO VISUALIZAÇÕES PARA FILTRAR PRIVILÉGIOS

Você pode tornar as ações de privilégio mais precisas usando visualizações. Sempre que você concede um privilégio em uma tabela base a um usuário, ele é automaticamente propagado para todas as linhas e, ao utilizar as possíveis exceções UPDATE e REFERENCES, para todas as colunas da tabela. Ao criar uma visualização que faça referência à tabela subjacente e, em seguida, transfira o privilégio para a visualização em vez de para a tabela, você pode restringir esses privilégios a quaisquer expressões na consulta contida na visualização. Isto melhora muito os recursos básicos do comando GRANT.

QUEM PODE FAZER INSCRIÇÕES?

Para criar uma visualização, você deve ter o privilégio SELECT em todas as tabelas às quais você faz referência na visualização. Se a visualização for modificável, quaisquer privilégios INSERT, UPDATE e DELETE que você tiver na tabela base serão automaticamente transferidos para a visualização. Se você não tiver privilégios de modificação nas tabelas base, não poderá tê-los nas visualizações que criar, mesmo que essas visualizações sejam modificáveis. Como as chaves estrangeiras não são usadas em visualizações, o privilégio REFERENCES nunca é usado ao criar visualizações. Todas essas restrições são definidas pela ANSI. Privilégios de sistema não padrão (discutidos posteriormente neste capítulo) também podem ser ativados. Nas seções a seguir, assumiremos que os criadores das visualizações que discutimos possuem privilégios privados ou apropriados em todas as tabelas subjacentes.

LIMITANDO O PRIVILÉGIO DE SELEÇÃO EM COLUNAS ESPECÍFICAS

Digamos que você queira dar ao usuário Claire a capacidade de ver apenas as colunas snum e sname da tabela Sales. Você pode fazer isso colocando os nomes dessas colunas na visualização

CREATE VIEW Clairesview AS SELECT snum, sname FROM Vendedores; e conceda a Claire o privilégio SELECT na visualização em vez de na própria tabela Sellers: GRANT SELECT On Clairesview to Claire; Você pode criar privilégios especificamente para colunas, como usar outros privilégios, mas para um comando INSERT isso inserirá valores padrão e, para um comando DELETE, a restrição de coluna não terá efeito. Os privilégios REFERENCES e UPDATE podem, é claro, tornar colunas específicas sem recorrer a uma visualização.

LIMITANDO PRIVILÉGIOS PARA STRINGS ESPECÍFICOS Normalmente, uma maneira mais útil de filtrar privilégios com visualizações é usar a visualização para fazer com que o privilégio se aplique apenas a determinadas linhas. Você faz isso naturalmente usando um predicado na visualização que determinará quais linhas serão incluídas. Para dar ao usuário Adrian o privilégio UPDATE na tabela Clientes para todos os clientes localizados em Londres, você poderia criar uma visão como esta:

CRIAR VISUALIZAÇÃO Londoncust AS SELECT * FROM Clientes WHERE cidade = "London" COM OPÇÃO CHECK; Você deve então conceder o privilégio UPDATE nesta tabela para Adrian: GRANT UPDATE ON Londoncust TO Adrian; Esta é a diferença entre o privilégio para determinadas linhas e o privilégio UPDATE para determinadas colunas, que se aplica a todas as colunas da tabela Clientes, mas não às linhas, entre as quais não serão levadas em consideração as linhas com valor de gênero de cidade diferente de Londres. . A cláusula WITH CHECK OPTION impede que Adrian altere o valor do gênero da cidade para qualquer outro valor que não seja Londres. FORNECENDO ACESSO SOMENTE AOS DADOS EXTRAÍDOS Outra possibilidade é oferecer aos usuários acesso aos dados que já foram recuperados, em vez dos valores reais da tabela. Funções agregadas podem ser muito convenientes ao usar este método. Você pode criar uma visualização que forneça a contagem, a média e o total dos pedidos para cada dia do pedido: CREATE VIEW Datetotals AS SELECT odate, COUNT (*), SUM (amt), AVG (amt) FROM Orders GROUP BY odate; Agora você concede à usuária Diane o privilégio SELECT na visualização Datetotals: GRANT SELECT ON Datetotals TO Diane; USANDO REPRESENTAÇÕES COMO ALTERNATIVA ÀS RESTRIÇÕES Uma das aplicações mais recentes da série, descrita no Capítulo 18, é o uso de visualizações com WITH CHECK OPTION como alternativa às restrições. Digamos que você queira ter certeza de que todos os valores de gênero da cidade na tabela Fornecedores estão em uma das cidades onde sua empresa possui atualmente um escritório. Você pode definir uma restrição CHECK diretamente na coluna da cidade, mas pode ser difícil alterá-la posteriormente se sua empresa abrir outros departamentos lá, por exemplo. Alternativamente, você pode criar uma visão que exclui valores de cidade inválidos: CREATE VIEW Curcities AS SELECT * FROM Salespeople WHERE city IN ("London", "Rome", "San Jose", "Berlin") WITH CHECK OPTION; Agora, em vez de conceder privilégios de modificação aos usuários na tabela Comerciantes, você pode concedê-los na visualização Curcities. A vantagem dessa abordagem é que, se você precisar fazer uma alteração, poderá excluir essa visualização, criar uma nova e conceder privilégios aos usuários nessa nova visualização, o que é mais fácil do que alterar as restrições. A desvantagem é que o proprietário da tabela Vendas também deve utilizar esta visão se não quiser que seus próprios comandos sejam rejeitados. Por outro lado, esta abordagem permite que o proprietário da tabela e qualquer outra pessoa obtenha privilégios de modificação na própria tabela, em vez de na visualização, para fazer exceções às restrições.

Muitas vezes isso é desejável, mas não é viável se você estiver usando restrições na tabela base. Infelizmente, essas exceções não serão visíveis na visualização. Se você escolher esta abordagem, você desejará criar uma segunda visualização contendo apenas exceções: CREATE VIEW Othercities AS SELECT * FROM Salespeople WHERE city NOT IN ("London", "Rome", "San Jose", "Berlin") COM VERIFICAR OPÇÃO; Você deve optar por conceder aos usuários apenas o privilégio SELECT nesta visualização para que eles possam ver as linhas excluídas, mas não possam colocar valores de cidade inválidos na tabela subjacente. Na verdade, os usuários poderiam consultar ambas as visualizações em uma união e ver todas as linhas de uma só vez.

OUTROS TIPOS DE PRIVILÉGIOS

Claro, você quer saber quem tem o direito de criar a tabela primeiro. Esta área privilegiada não é ANSI, mas não pode ser ignorada. Todos os privilégios ANSI padrão são derivados deste privilégio; privilégios de criadores de tabelas que podem transferir privilégios de objetos. Se todos os seus usuários criarem tabelas base no sistema com tamanhos diferentes isso levará à redundância deles e à ineficiência do sistema. Outras questões também chamam a atenção:

Quem tem o direito de alterar, excluir ou limitar tabelas?

Os direitos para criar tabelas base deveriam ser diferentes dos direitos para criar visualizações?

Deveria haver um superusuário - um usuário responsável pela manutenção do banco de dados e, portanto, com a maioria ou todos os privilégios que não são concedidos individualmente?

Até que o ANSI esteja envolvido e o SQL seja usado em vários ambientes, não poderemos dar uma resposta definitiva a essas questões. Propomos considerar aqui uma parte das conclusões mais gerais.

Os privilégios que não são definidos em termos de objetos de dados especiais são chamados de privilégios de sistema ou direitos de banco de dados. Em um nível básico, isso provavelmente incluirá o direito de criar objetos de dados, provavelmente diferentes de tabelas base (geralmente criadas por alguns usuários) e visualizações (geralmente criadas pela maioria dos usuários). Os privilégios de sistema para a criação de visualizações devem ser adicionais, e não substitutos, aos privilégios de objeto que o ANSI exige dos criadores de visualizações (descritos anteriormente neste capítulo). Além disso, em um sistema de qualquer tamanho sempre existem alguns tipos de superusuários – usuários que possuem automaticamente a maioria ou todos os privilégios – e que podem transferir seu status de superusuário para outra pessoa por meio de um privilégio ou grupo de privilégios. Administrador de banco de dados, ou DBA, é o termo mais comumente usado para esse superusuário e os privilégios que ele possui.

PRIVILÉGIOS TÍPICOS DO SISTEMA

De forma geral, existem três privilégios básicos de sistema: - CONNECT, - RESOURCE e - DBA (Administrador de Banco de Dados). Em termos mais simples, pode-se dizer que CONNECT consiste no direito de registro e no direito de criar visualizações e sinônimos (veja o Capítulo 23) se os privilégios do objeto forem passados. RESOURCE consiste no direito de criar tabelas base. DBA é um privilégio de superusuário que dá ao usuário alta autoridade no banco de dados. Um ou mais usuários com funcionalidade de administrador de banco de dados podem ter esse privilégio. Alguns sistemas também possuem um usuário especial, às vezes chamado SYSADM ou SYS (System Database Administrator), que possui a autoridade mais alta; é especial para eles, e não apenas para um usuário com privilégios especiais de DBA. Na verdade, apenas uma pessoa pode se registrar com o nome SYSADM, que é o seu ID de acesso. A distinção é bastante sutil e funciona de maneira diferente em sistemas diferentes. Para nossos propósitos, nos referiremos a um usuário altamente privilegiado que desenvolve e gerencia um banco de dados com privilégios de DBA, entendendo que na verdade esses privilégios são o mesmo privilégio. O comando GRANT, em formato modificado, pode ser usado tanto com privilégios de objeto quanto com privilégios de sistema. Para começar, a transferência de direitos pode ser feita por meio de um DBA. Por exemplo, um DBA poderia conceder privilégio de criação de tabela a Rodriguez da seguinte forma: GRANT RESOURCE TO Rodriguez;

CRIAR E EXCLUIR USUÁRIOS

Naturalmente, surge a pergunta: de onde vem um usuário chamado Rodriguez? Como determinar seu ID de liberação? Na maioria das implementações, o DBA cria o usuário concedendo-lhe automaticamente o privilégio CONNECT. Neste caso, geralmente é adicionada uma cláusula IDENTIFIED BY para indicar a senha. (Caso contrário, o sistema operacional deverá determinar se você pode efetuar login no banco de dados com o ID de acesso fornecido.) O DBA poderia, por exemplo, emitir GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon; que criará um usuário chamado Thelonius, dará a ele o direito de se registrar e atribuirá a senha Redwagon, tudo em uma frase. Como Thelonious já é um usuário autenticado, ele ou o DBA podem utilizar este mesmo comando para alterar a senha do Redwagon. Embora isto seja conveniente, ainda existem limitações nesta abordagem. Trata-se da impossibilidade de ter um usuário que não conseguiu se cadastrar, pelo menos temporariamente. Se quiser impedir que um usuário faça login, você deve usar o privilégio CONNECT em REVOKE, que "remove" esse usuário. Algumas implementações permitem criar e excluir usuários, independentemente de seus privilégios de login. Ao conceder o privilégio CONNECT a um usuário, você cria esse usuário. Além disso, para fazer isso sozinho, você deve ter privilégio de DBA. Se esse usuário criar tabelas base (não apenas visualizações), ele também deverá receber o privilégio RESOURCE. Mas isto dá imediatamente origem a outro problema. Se você tentar remover o privilégio CONNECT de um usuário que possui tabelas criadas por ele, o comando será rejeitado porque deixaria a tabela sem dono, o que não é permitido. Você deve primeiro eliminar todas as tabelas criadas por este usuário antes de remover seu privilégio CONNECT. Se essas tabelas não estiverem vazias, provavelmente você desejará passar seus dados para outras tabelas usando o comando INSERT, que usa uma consulta. Não é necessário remover o privilégio RESOURSE separadamente; Basta excluir CONNECT para excluir o usuário. Embora a abordagem acima seja uma abordagem bastante padrão para privilégios de sistema, ela também tem limitações significativas. Surgiram abordagens alternativas que são definidas de forma mais específica e controlam os privilégios do sistema com mais precisão.

Essas conclusões nos levam um pouco além do padrão SQL conforme definido atualmente e, em algumas implementações, podem ir além do padrão SQL inteiramente. Essas coisas provavelmente não lhe preocuparão muito, a menos que você seja um DBA ou usuário alto nível. Os usuários regulares precisam apenas estar familiarizados com os privilégios do sistema em princípio, consultando sua documentação apenas em caso de mensagens especiais.

RESUMO

Os privilégios permitem ver o SQL de uma nova perspectiva quando o SQL executa ações por meio de usuários especiais em um sistema de banco de dados especial. O comando GRANT em si é bastante simples: com sua ajuda você concede certos privilégios de um objeto a um ou mais usuários. Se você conceder o privilégio WITH GRANT OPTION a um usuário, esse usuário poderá, por sua vez, conceder esse privilégio a outros. Agora você entende as dicas sobre o uso de privilégios em visualizações — para aprimorar privilégios em tabelas base ou como alternativa a restrições — e algumas das vantagens e desvantagens dessa abordagem. Os privilégios de sistema que são necessários, mas não estão dentro do escopo do padrão SQL, foram discutidos em sua forma mais geral e, portanto, você os aprenderá na prática. O Capítulo 23 continuará a discussão sobre inferência em SQL, como salvar ou restaurar alterações, criar seus próprios nomes para tabelas pertencentes a outras pessoas e compreender o que acontece quando diferentes usuários tentam acessar o mesmo objeto ao mesmo tempo.

TRABALHANDO COM SQL

1. Dê a Janet o direito de alterar a avaliação do cliente.

2. Dê a Stephan o direito de conceder a outros usuários o direito de fazer consultas na tabela Pedidos.

3. Remova o privilégio INSERT na tabela Vendors de Claire e de todos os usuários aos quais ele foi concedido.

4. Dê a Jerry o direito de inserir ou modificar a tabela Clientes, mantendo sua capacidade de avaliar valores na faixa de 100 a 500.

5. Permita que Janet consulte a tabela Cliente, mas evite que ela diminua as classificações na mesma tabela Cliente.

A plataforma SQL Server usa a instrução REVOKE como forma de revogar as configurações de permissão atribuídas a um determinado usuário. Este ponto é importante porque o SQL Server oferece suporte a uma instrução DENY adicional que nega explicitamente ao usuário o acesso a um recurso especificado. No SQL Server, a instrução REVOKE pode ser usada para revogar privilégios atribuídos a um usuário usando a instrução GRANT. Se você deseja negar explicitamente a um usuário um determinado privilégio, você deve usar a instrução DENY.

A plataforma SQL Server não oferece suporte às cláusulas ANSI HIERARCHY OPTION e ADMIN OPTION. Embora a cláusula ADMIN OPTION não seja suportada, a versão do comando REVOKE do SQL Server tem dois privilégios administrativos (CREATE e BACKUP). A sintaxe da instrução é a seguinte.

REVOKE ([object_privilege] [, ...] | [system_privilege]) [(coluna [, ...])]]| (PARA | DE) (nome_destinatário [, …] | função [, …] | PÚBLICO | CONVIDADO)]

OPÇÃO DE CONCESSÃO PARA

O usuário fica privado do direito de atribuir privilégios específicos a outros usuários.

privilégio de objeto

São revogados os direitos de acesso a diversas instruções, que podem ser combinadas em qualquer ordem.

TODOS

Todos os privilégios atribuídos em atualmente usuários especificados e/ou para objetos de banco de dados especificados. Esta sugestão é desencorajada porque promove ambiguidade de programação.

(SELECIONAR | INSERIR EXCLUIR ATUALIZAÇÃO)

O usuário especificado tem o privilégio de acesso especificado negado no objeto especificado (por exemplo, uma tabela ou visualização). Para revogar privilégios em nível de coluna, use uma lista de colunas entre parênteses.

REFERÊNCIAS

O direito de criar e excluir restrições de chave estrangeira que fazem referência a um objeto de banco de dados como objeto pai é revogado.

O direito do usuário de criar ou excluir uma regra em uma tabela ou visualização é revogado.

O direito de executar um procedimento armazenado, uma função definida pelo usuário ou um procedimento armazenado estendido é revogado.

privilégio de sistema

É revogado o direito de executar as seguintes instruções: CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLE, CREATE VIEW, BACKUP DATABASE e BACKUP LOG.

ON [objeto] [(coluna [, ...])]

O direito de acesso do usuário ao objeto especificado é revogado. Se o objeto for uma tabela ou visualização, você poderá revogar privilégios de acesso em colunas individuais. Você pode revogar os privilégios SELECT, INSERT, UPDATE, DELETE e REFERENCES em uma tabela ou visualização. Em colunas de tabela ou visualização, você só pode revogar privilégios SELECT e UPDATE. Você pode revogar privilégios EXECUTE em um procedimento armazenado, função definida pelo usuário ou procedimento armazenado estendido.

[PARA | DE] nome do destinatário | papel | PÚBLICO | CONVIDADO

Especifica os usuários ou funções que perdem o privilégio especificado. Você pode usar a palavra-chave PUBLIC para revogar privilégios atribuídos à função PUBLIC (que inclui todos os usuários). Você pode listar vários destinatários, separando seus nomes com vírgulas. Também compatível com SQL Server Conta GUEST, que é utilizado por todos os usuários que não possuem entrada própria no banco de dados.

Os privilégios dos usuários que receberam seus direitos através da cláusula WITH GRANT OPTION são removidos. Esta cláusula é necessária ao usar a cláusula GRANT OPTION FOR.

AS (nome_grupo nome_função)

Os direitos sob os quais o privilégio é revogado são indicados. Em alguns casos, um usuário pode precisar temporariamente dos direitos de um grupo específico para substituir os privilégios especificados. Neste caso, você pode utilizar a cláusula AS para obter tais direitos.

As duas formas da instrução REVOKE, privilégio de objeto REVOKE e privilégio_de_sistema REVOKE, são mutuamente exclusivas. Não tente fazer as duas operações em uma instrução. A principal diferença sintática entre os dois é que você não deve usar a cláusula ON ao remover privilégios do sistema. Por exemplo, para remover um privilégio do sistema, você pode usar o seguinte comando.

REVOGAR CRIAR BANCO DE DADOS, BACKUP DE BANCO DE DADOS DE dylan, katie

Se privilégios foram atribuídos a um usuário usando a cláusula WITH GRANT OPTION, esses privilégios deverão ser revogados usando duas cláusulas ao mesmo tempo - WITH GRANT OPTION e CASCADE. Por exemplo:

REVOGAR OPÇÃO DE CONCESSÃO PARA SELECT, INSERT, UPDATE, DELETE ON títulos PARA editores CASCADE GO

O comando REVOKE só pode ser usado no banco de dados atual. Conseqüentemente, as opções do padrão ANSI CURRENTJJSER e CURRENTROLE são sempre assumidas implicitamente. A instrução REVOKE também é usada para cancelar todas as opções DENY.

A plataforma SQL Server também oferece suporte a uma instrução DENY adicional. A sintaxe da instrução DENY é idêntica à sintaxe da instrução REVOKE. No entanto, em essência, eles diferem porque REVOKE neutraliza os privilégios do usuário, enquanto DENY os proíbe explicitamente. Use a instrução DENY para negar a um usuário ou função o acesso a um privilégio, mesmo que o privilégio seja concedido explicitamente ou por meio de atribuição de função.

A instrução REVOKE deve ser usada para remover privilégios concedidos anteriormente ou DENY. Por exemplo, a usuária Kelly entrou em licença maternidade prolongada. Durante esse período, seu acesso à mesa de funcionários foi negado. Ela voltou e permitimos privilégios novamente.

NEGAR TUDO DO FUNCIONÁRIO PARA Kelly GO

REVOGAR TODOS OS FUNCIONÁRIOS PARA Kelly GO

Neste exemplo, o comando REVOKE não remove seus privilégios; ele substitui o comando DENY.

A criação de um usuário por si só não concede ao usuário quaisquer direitos de acesso aos objetos do banco de dados.

As permissões são concedidas pelo comando GRANT. Deve-se lembrar que o usuário que emite o comando GRANT pode transferir ou, se preferir, delegar a outros usuários apenas os direitos que ele próprio possui.

GRANT define direitos em objetos de banco de dados para usuários, funções ou outros objetos de banco de dados. Quando um objeto é criado, somente seu criador tem direitos sobre ele, e somente ele pode conceder direitos a outros usuários ou objetos.

Para acessar uma tabela ou visualização, o usuário ou objeto precisa dos direitos SELECT, INSERT, UPDATE, DELETE ou REFERENCES. Todos os direitos podem ser concedidos com a opção ALL.

Para chamar um procedimento em uma aplicação, o usuário deve ter direitos EXECUTE.

Os usuários podem obter permissão para conceder direitos a outros usuários transferindo direitos de acordo com a lista , que é especificado pela opção WITH GRANT OPTION. O usuário pode conceder a terceiros apenas os direitos que ele próprio possui.

As permissões podem ser concedidas a todos os usuários usando a opção PUBLIC no lugar da lista de nomes de usuários. A especificação da opção PUBLIC afeta apenas os usuários, não os objetos do banco de dados.

A lista de direitos é apresentada na tabela. 8.5.

Tabela 8.5. Lista de direitos

Os direitos podem ser revogados pelo usuário que os concedeu usando o comando REVOKE. Se os direitos foram emitidos através de ALL, então só podem ser liquidados na modalidade ALL; se os direitos foram emitidos através de PUBLIC, então só podem ser liquidados na modalidade PUBLIC.

Sintaxe:

GRANT (todos /PRIVILÉGIOS] / LJST_ ) NA MESA ]

(nome da tabela/nome da visualização)

PARA(