Gerenciamento das Contas dos Utilizadores no MySQL - XOOPS Brasil
GRANT priv_type [(column_list)] [, tipo_priv [(column_list)] ...]
O comando GRANT é implementado no MySQL versão 3.22.11 ou posterior. Para versões anteriores do MySQL, a instrução GRANT não faz nada.
Os comandos GRANT e REVOKE permitem aos administradores do sistema criar utilizadores e conceder e revogar direitos aos utilizadores do MySQL em quatro níveis de privilégios:
Privilégios globais aplicam para todos os bancos de dados em um determinado servidor. Estes privilégios são armazenados na tabela mysql.user. GRANT ALL ON *.* e REVOKE ALL ON *.* concederão e revogarão apenas privilégios globais.
Nível dos bancos de dados
Privilégios de bancos de dados aplicam-se a todas as tabelas em um determinado banco de dados. Estes privilégios são armazenados nas tabelas mysql.db e mysql.host. GRANT ALL ON db.* e REVOKE ALL ON db.* concederão e revogarão apenas privilégios de banco de dados.
Nível das tabelas
Privilégios de tabelas aplicam-se a todas as colunas em uma determinada tabela. Estes privilégios são armazenados na tabela mysql.tables_priv. GRANT ALL ON db.table e REVOKE ALL ON db.table concederão e revogarão apenas privilégios de tabelas.
Nível das colunas
Privilégios de colunas aplicam-se a uma única coluna em uma determinada tabela. Estes privilégios são armazenados na tabela mysql.columns_priv.
Para as instruções GRANT e REVOKE, tipo_priv pode ser especificado como um dos seguintes:
ALL [PRIVILEGES] Configura todos os privilégios simples exceto WITH GRANT OPTION
ALTER Permite o uso de ALTER TABLE
CREATE Permite o uso de CREATE TABLE
CREATE TEMPORARY TABLES Permite o uso de CREATE TEMPORARY TABLE
DELETE Permite o uso de DELETE
DROP Permite o uso de DROP TABLE.
EXECUTE Permite que o utilizador execute stored procedures (MySQL 5.0)
FILE Permite o uso de SELECT ... INTO OUTFILE e LOAD DATA INFILE.
INDEX Permite o uso de CREATE INDEX e DROP INDEX
INSERT Permite o uso de INSERT
LOCK TABLES Permite o uso de LOCK TABLES em tabelas nas quais se tem o privilégio SELECT.
PROCESS Permite o uso de SHOW FULL PROCESSLIST
REFERENCES Para o futuro
RELOAD Permite o uso de FLUSH
REPLICATION CLIENT Da o direto ao utilizador de perguntar onde o slave/master está.
REPLICATION SLAVE Necessário para a replicação dos slaves (para ler logs binário do master).
SELECT Permite o uso de SELECT
SHOW DATABASES SHOW DATABASES mostra todos os banco de dados.
SHUTDOWN Permite o uso de mysqladmin shutdown
SUPER Permite a conexão (uma vez) mesmo se max_connections tiverem sido alcançados e executa o comando CHANGE MASTER, KILL thread, mysqladmin debug, PURGE MASTER LOGS e SET GLOBAL
UPDATE Permite o uso de UPDATE
USAGE Sinônimo para ``sem privilégios.''
GRANT OPTION Sinônimo para WITH GRANT OPTION
USAGE pode ser usado quando você quer criar um utilizador 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 usar estes novos privilégios após atualizar para 4.0.2, você tem que executar o script mysql_fix_privilege_tables. Veja mais informações sobre isto na Seção 2.5.6, "Atualizando a Tabela de Permissões".
Em versões anteriores do MySQL, o privilégio PROCESS dá o mesmo direitos que o novo privilégio SUPER.
Para anular o privilégio grant de um utilizador, utilize o valor tipo_priv de GRANT OPTION:
Os únicos valores de tipo_priv que você pode especificar para uma tabela são SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, INDEX e ALTER.
Os únicos valores de tipo_priv que você pode especificar para uma coluna (isto é, quando você usar uma cláusula column_list) são SELECT, INSERT e UPDATE.
O MySQL permite que você crie privilégios a nível de banco de dados mesmo se o banco de dados não existir para tornar fácil de se preparar para o uso do banco de dados. Atualmente, no entanto, o MySQL não permite criar permissões de a nível de tabela se a tabela não existir. O MySQL não revogará automaticamente qualquer privilégio, mesmo se você apagar uma tabela ou banco de dados.
Você pode configurar privilégios globais utilizando a sintaxe ON *.*. Você pode configurar privilégios de bancos de dados utilizando a sintaxe ON nome_bd.*. Se você especificar ON * e estiver com algum banco de dados aberto, será configurado os privilégios somente para este banco de dados. (AVISO: Se você especificar ON * e você não tem possui um banco de dados aberto, irá afetar os privilégios globais!).
Note por favor Os metacaracteres '_' e '%' são permitidos na especificação dos nomes de bancos de dados em comandos GRANT. Isto significa que se você deseja usar um caracater '_' como parte de um nome de banco de dados, você deve especificá-lo como '\_' no comando GRANT, para prevenir o utilizador de poder acessar bancos de dados adicionais que correspondam ao padrão do metacaracter, ex., GRANT ... ON `foo\_bar`.* TO ....
Para acomodar concessões de direitos para utilizadores de máquinas arbitrárias, o MySQL suporta a especificação do valor user_name no formato utilizador@máquina. Se você desejar especificar uma string user contendo caracteres especiais (como o '-'), ou uma string contendo caracteres especiais ou meta caracteres (como o '%'), você pode colocar o utilizador ou o nome de máquina entre aspas (por exemplo, 'utilizador-teste'@'máquina-teste').
Você pode especificar meta caracteres no nome da máquina. Por exemplo, user@"%.loc.gov" se aplica a user para qualquer máquina no domínio loc.gov, e user@"144.155.166.%" se aplica a user em qualquer máquina na subrede de classe C 144.155.166.
O formato simples user é sinônimo de user@"%".
O MySQL não suporta metacaracteres em nomes de utilizadores. Utilizadores anônimos são definidos inserindo entradas com User='' na tabela mysql.user ou criando um utilizador com um nome vazio com o comando GRANT.
Nota: Se você permite o acesso de utilizadores anônimos ao seu servidor MySQL, você deve também concecder privilégios a todos os utilizadores locais como user@localhost porque, de outra forma, a entrada de utilizador anônimo para a máquina local na tabela mysql.user será usada quando o utilizador tentar a conexão ao servidor MySQL da máquina local!
Você pode verificar se isto se aplica a você executando a seguinte instrução:
No momento, GRANT suporta somente nomes de máquinas, tabelas bancos de dados e colunas até 60 caracteres. Um nome de utilizador pode ter até 16 caracteres.
Os privilégios para uma tabela ou coluna são formados através do OU lógico dos privilégios em cada um dos quatro níveis de privilégios. Por exemplo, se a tabela mysql.user especifica que um utilizador tem um privilégio global select, isto não pode ser negado por uma entrada no nível de banco de dados, tabela ou coluna.
Os privilégios para uma coluna podem ser calculados da seguinte forma:
OR (privilégios de banco de dados AND privilégios de máquina)
OR privilégios de tabela
OR privilégios de coluna
Na maioria dos casos, os direitos a um utilizador são atribuídos em apenas um dos níveis de privilégios, portanto a vida normalmente não é tão complicada como mostrado acima. Os detalhes do procedimento de verificação dos privilégios são apresentados em Seção 4.3, "Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MySQL".
Se você concede privilégios para uma combinação de utilizador e máquina que não existem na tabela mysql.user, um registro é adicionado e permanece lá até ser removido com um comando DELETE. Em outras palavras, GRANT pode criar registros na tabela user, mas REVOKE não as removerá; para removê-las você deve usar a instrução explícita DELETE.
Na Versão 3.22.12 ou posterior do MySQL, se um novo utilizador é criado ou se você possui privilégios de concessão globais, a senha do utilizador será especificada utilizando a cláusula IDENTIFIED BY, se uma for dada. Se o utilizador já possui uma senha, ela é trocada pela nova.
Se você não quiser enviar a senha em texto puro você pode usar a opção PASSWORD seguido de uma senha embaralhada da função SQL PASSWORD() ou da função da API C make_scrambled_password(char *to, const char *password).
CUIDADO: Se você criar um novo utilizador mas não especificar uma cláusula IDENTIFIED BY, o utilizador não possuirá uma senha. Isto não é seguro.
Senhas podem também ser configuradas com o comando SET PASSWORD. Veja mais informações sobre isto na Seção 5.5.6, "Sintaxe de SET".
Se você conceder privilégios para um banco de dados, uma entrada na tabela mysql.db é criada se necessário. Quando todos os privilégios para o banco de dados forem removidos com REVOKE, este registro é removido.
Se um utilizador não tem privilégios em uma tabela, a tabela não é mostrada quando o utilizador solicita uma lista de tabelas (com a instrução SHOW TABLES por exemplo). O mesmo é verdade para SHOW DATABASES
A cláusula WITH GRANT OPTION dá ao utilizador habilidade de fornecer à outros utilizadores quaisquer privilégios que ele tenha em um nível específico de privilégio. Você deve ter cuidado ao fornecer o privilégio grant, pois dois utilizadores podem se unir para unir privilégios!
MAX_QUERIES_PER_HOUR #, MAX_UPDATES_PER_HOUR # e MAX_CONNECTIONS_PER_HOUR # sãp novos no MySQL versão 4.0.2. Estas opções limitam o número de consultas/atualizações e logins que o utilizadores pode fazer durente uma hora. Se # é 0 (padrão), então isto significa que não há limites para aquele utilizador. Veja mais informações sobre isto na Seção 4.4.7, "Limitando os Recursos dos Utilizadores". Nota: para especificar qualquer destas opções para um utilizador existente sem adicionar outros privilégios adicionais, use GRANT USAGE ON *.* ... WITH MAX_....
Você não pode conceder a outro utilizador um privilégio que não possua; o privilégio GRANT possibilita fornecer somente os privilégios que possuir.
Esteja ciente que quando conceder a um utilizador o privilégio GRANT em um nível particular de privilégios, qualquer privilégio que o utilizador já possua (ou seja fornecido no futuro!) nesse nível também pode ser concedido por este utilizador. Suponha que você conceda a um utilizador 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 utilizador além de poder repassar o privilégio SELECT poderá também repassar o insert. Se você concede o privilégio UPDATE para o utilizador no banco de dados, o utilizador poderá conceder os privilégios INSERT, SELECT e UPDATE.
Você não deve conceder privilégios ALTER a um utilizador comum. Se você fizer isto, o utilizador pode tentar enganar o sistema de privilégios renomeando tabelas!
Perceba que se você estiver utilizando privilégios de tabelas ou colunas, mesmo que para apenas um utilizador, o servidor examina os privilégios de tabelas e colunas para todos os utilizadores e isto irá deixar o MySQL um pouco mais lento.
Quando o mysqld inicia, todos os privilégios são lidos na memória. Privilégios de bancos de dados, tabelas e colunas são iniciados um vez, e privilégios ao nível de utilizador fazem efeito na próxima vez que o utilizador conectar. Modificações nas tabelas de permissões que você realiza utilizando GRANT ou REVOKE são percebidas pelo servidor imediatamente. Se você modificar as tabelas de permissões manualmente (utilizando INSERT, UPDATE, etc), você deve executar uma instrução FLUSH PRIVILEGES ou executar mysqladmin flush-privileges para dizer ao servidor para recarregar as tabelas de permissões. Veja mais informações sobre isto na Seção 4.4.3, "Quando as Alterações nos Privilégios tem Efeito".
As maiores diferenças entre o padrão SQL e versões MySQL de GRANT são:
No MySQL privilégios são fornecidos para uma combinação de utilizador e máquina e não somente para um utilizador.
O SQL-99 não possui privilégios no nível global ou de bancos de dados, e não suporta todos os tipos de privilégios que o MySQL suporta. O MySQL não suporta os privilégios TRIGGER, EXECUTE ou UNDER do SQL-99.
Os privilégios do SQL-99 são estruturadados em uma maneira hierárquica. Se você remover um utilizador, todos os privilégios do utilizador são removidos. No MySQL os privilégios concedidos não são removidos automaticamente, mas você deve removê-los se necessário.
Se no MySQL você possuir o privilégio INSERT em somente parte das colunas em uma tabela, você pode executar instruções INSERT na tabela; As colunas em que você não tem o privilégio INSERT irão receber seus valores padrões. O SQL-99 necessita que você tenha o privilégio INSERT em todas as colunas.
Quando você remove uma tabela no SQL-99, todos os privilégios para a tabela são removidos. Se você remover um privilégio no SQL-99, todos os privilégios que foram concedidos baseado neste privilégio são também removidos. No MySQL, privilégios só podem ser removidos com comandos REVOKE explícitos ou manipulando as tabelas de permissões do MySQL.
Para uma descrição do uso de REQUIRE, veja Seção 4.4.10, "Usando Conexões Seguras".
Existem várias diferenças entre a forma que nomes de utilizadores e senhas são usados pelo MySQL e a forma que são usados pelo Unix ou Windows:
Nomes de utilizadores, como usado pelo MySQL para propósitos de autenticação, não tem nenhuma relação com os nomes de utilizadores do Unix (nomes de login) ou nomes de utilizadores Windows. A maioria dos clientes MySQL, por padrão, tentam se conectar utilizando o nome de utilizador atual do Unix como o nome de utilizador no MySQL, mas isto existe somente por conveniência. Programas clientes permite especificar um nome diferente com as opções -u ou --user. Isto significa que você não pode tornar um banco de dados seguro a menos que todos os utilizadores do MySQL possuam senhas. Qualquer um pode tentar se conectar ao servidor utilizando qualquer nome, e eles se conectarão com qualquer nome que não possua uma senha.
Nomes de utilizadores MySQL podem ter o tamanho de até 16 caracteres; Nomes de utilizador Unix normalmente são limitados até 8 caracteres.
Senhas MySQL não tem nenhuma relação com senhas Unix. Não existe nenhuma associação entre a senha em que você utiliza para logar-se a uma máquina Unix e a senha que é utilizada para acessar um banco de dados na mesma máquina.
O MySQL criptografa senhas utilizando um algorítimo diferente que o utilizado pelo processo de login do Unix. Veja as descrições das funções PASSWORD() e ENCRYPT() em Seção 6.3.6.2, "Funções Diversas". Perceba que mesmo que a senha é armazenada 'embaralhada', o conhecimento da sua senha 'embaralhada' é o suficiente para conseguir se conectar ao servidor MySQL!
A partir da versão 4.1, o MySQL emprega um mecanismo de senha e login diferentes que é seguro mesmo se for feito um sniff no pacote TCP/IP e/ou o banco de dados mysql for capturado.
Utilizadores MySQL e seus privilégios são criados normalmente com o comando GRANT, Veja mais informações sobre isto na Seção 4.4.1, "A Sintaxe de GRANT e REVOKE".
Quando você se conecta a um servidor MySQL com um cliente de linha de comando você pode especificar a senha com --password=sua-senha. Veja mais informações sobre isto na Seção 4.3.8, "Conectando ao Servidor MySQL".
mysql --user=monty --password=guess nome_do_banco
Se você deseja que o cliente lhe solicite a senha, deve ser especificado o parâmetro --password sem nenhum argumento
mysql --user=monty --password nome_do_banco
ou no formato curto:
mysql -u monty -p nome_do_banco
Perceba que no último exemplo a senha não é 'nome_do_banco'.
Se você deseja usar a opção -p para fornecer uma senha você deve fazer assim:
Em alguns sistemas, a chamada da biblioteca que é utilizada pelo MySQL para solicitar por uma senha corta automaticamente a senha para 8 caracteres. Internamente o MySQL não limita o tamanho limite da senha.
Quando o mysqld inicia, todas o conteúdo das tabelas de permissões são lidos em memória e tem efeito neste momento.
As modificações das tabelas de permissões que você realiza utilizando GRANT, REVOKE ou SET PASSWORD são imediatamente reconhecidas pelo servidor.
Se você alterar as tabelas de permissões manualmente (utilizando INSERT, UPDATE, etc), você deve executar a instrução FLUSH PRIVILEGES ou executar mysqladmin flush-privileges ou mysqladmin reload para dizer ao servidor para recarregar as tabelas de permissões. De outra forma suas alterações não terão efeito até que o servidor seja reiniciado. Se você alterar as tabelas de permissões manualmente mas se esquecer de recarregar os privilégios, suas alteração vão parecer não ter feito nenhuma diferença!
Quando o servidor reconhecer que as tabelas de permissões foram alteradas, conexões existentes são afetadas da seguinte forma:
Alterações nos privilégios de tabelas e colunas fazem efeito com a próxima requisição do cliente.
Alterações nos privilégios de bancos de dados fazem efeito no próximo comando USE nome_bd.
Alterações nos privilégios globais e alterações de senhas fazem efeito na próxima vez que o cliente conectar.
Depois de instalar o MySQL, você configura os privilégios iniciais dos acessos executando scripts/mysql_install_db. Veja mais informações sobre isto na Seção 2.3.1, "Visão geral da instalação rápida". O script mysql_install_db inicia o servidor mysqld, depois inicializa as tabelas de permissões com a seguinte configuração dos privilégios:
O utilizador root do MySQL é criado como um superutilizador que pode fazer qualquer coisa. Conexões devem ser feitas através da máquina local.
NOTA: A senha inicial de root é vazia, portanto qualquer um que conectar como root sem senha terá direito a todos os privilégios.
Um utilizador anônimo é criado e pode fazer o que desejar com bancos de dados com nome 'test' ou iniciando com 'test_'. Conexões devem ser feitas da máquina local. Isto significa que utilizadores locais podem se conectar sem senha e serem tratados como utilizadores anônimos.
Outros privilégios são negados. Por exemplo, utilizadores normais não podem executar mysqladmin ou mysqladmin processlist.
NOTA: Os privilégios padrões são diferentes no Windows. Veja mais informações sobre isto na Seção 2.1.1.8, "Executando o MySQL no Windows".
Como sua instação inicialmente é parcialmente aberta, uma das primeiras coisas que você deve fazer é especificar uma senha para o utilizador root do MySQL. Você pode fazer isto como a seguir (perceba que a senha foi especificada utilizando a função PASSWORD()):
mysql> SET PASSWORD FOR root@localhost=PASSWORD('nova_senha');
Substitua 'nova_senha' pela senha que você deseja usar.
Se você souber o que esta fazendo, você também pode manipular diretamente a tabela privilégios:
Outra forma de configurar a senha é utilizando o comando mysqladmin:
shell> mysqladmin -u root password nova_senha
Somente utilizadores com acesso de escrita/atualização ao banco de dados mysql podem alterar a senha de outros utilizadores. Todos os utilizadores comuns (não os anônimos) podem alterar somente a própria senha com um dos comandos acima ou com SET PASSWORD=PASSWORD('nova_senha').
Perceba que se você atualizar a senha na tabela user diretamente utilizando UPDATE, você deve dizer ao servidor para reler as tabelas de permissões (com FLUSH PRIVILEGES), de outra forma a alteração não seria notificada.
Uma vez que a senha de root foi configurada, você deve informar a senha quando se conectar ao servidor MySQL como root.
Você pode desejar deixar a senha de root em branco para que você não precise especificá-la quando realizar configurações adicionais ou testes. Entretanto, tenha certeza de configurá-la antes de utilizar sua instalação para qualquer ambiente de produção.
Veja o script scripts/mysql_install_db para ver como são configurados os privilégios padrões. Você pode usar isto como uma base para ver como adicionar outros utilizadores.
Se você deseja que os privilégios iniciais sejam diferentes do descrito acima, é possível modificar o script mysql_install_db antes de executá-lo.
Para recriar as tabelas de permissões completamente, remova todos os arquivos .frm .MYI e .MYD no diretório contendo o banco de dados mysql. (Este é o diretório chamado mysql sob o diretório do banco de dados, que é listado quando você executa mysqld --help.) Depois execute o script mysql_install_db, possivelmente depois de editá-lo para criar os privilégios desejáveis.
NOTA: Para versões do MySQL mais antigas que a versão 3.22.10, você não deve apagar os arquivos .frm. Se você fizer isso acidentalmente, você deve voltá-los a partir de sua distribuição MySQL antes de executar mysql_install_db.
Existem duas maneiras de adicionar utilizadores: utilizando instruções GRANT ou manipulando as tabelas de permissões do MySQL diretamente. O método preferido é utilizar instruções GRANT, porque elas são mais concisas e menos propensas a erros. Veja mais informações sobre isto na Seção 4.4.1, "A Sintaxe de GRANT e REVOKE".
Existem vários programas de colaboradores (como o phpMyAdmin) que podem ser utilizados para criar e administrar utilizadores. Veja mais informações sobre isto na Apêndice B, Contribuição de Programas.
Os exemplos abaixo mostram como usar o cliente mysql para configurar novos utilizadores. Estes exemplos assumem que privilégios são configurados de acordo com os padrões descritos na seção anterior. Isto significa que para fazer alterações, você deve se conectar na mesma máquina em que o mysqld está executando, você deve se conectar com o utilizador root, e o utilizador root deve ter os privilégios inster ao banco de dados mysql e o administrativo reload. Também, se você alterou a senha do utilizador root, você deve especificá-la para os comandos mysql abaixo.
Primeiro, use o programa mysql para se conectar ao servidor como o utilizador root do MySQL:
Você pode adicionar novos utilizadores utilizando instruções GRANT:
Estas instruções GRANT configuram três novos utilizadores:
Um superutilizador completo que pode conectar ao servidor de qualquer lugar, mas deve utilizar uma senha 'alguma_senha' para fazer isto. Perceba que devemos utilizar instruções GRANT para monty@localhost e monty@"%". Se nós não adicionarmos a entrada com localhost, a entrada para o utilizador anônimo para localhost que é criada por mysql_install_db toma precedência quando nos conectarmos da máquina local, porque ele contem um campo Host com um valor mais específico e também vem antes na ordenação da tabela user.
Um utilizador que possa conectar de localhost sem uma senha e que é concedido os privilégios administrativos reload e process. Isto permite ao utilizador a execução dos comandos mysqladmin reload, mysqladmin refresh e mysqladmin flush-*, bem como o mysqladmin processlist. Nenhum privilégio a nível de bancos de dados é concedido. (Depois eles podem ser adicionados utilizando instruções GRANT adicionais.)
Um utilizador que pode conectar sem uma senha, mas somente na máquina local. Não são concedidos nenhum privilégio---o tipo de privilégio USAGE permite a criação de um utilizador sem privilégios. Ele tem o efeito de criar todos os privilégios globais com 'N'. Considera-se que você irá conceder privilégios específicos a conta posteriormente.
Também é possível adicionar a mesma informação de acesso do utilizador diretamente, utilizando instruções INSERT e depois dizendo ao servidor para recarregar as tabelas de permissões:
mysql> INSERT INTO user VALUES('localhost','monty',PASSWORD('alguma_senha'),
mysql> INSERT INTO user VALUES('%','monty',PASSWORD('alguma_senha'),
Dependendo da sua versão do MySQL, você pode precisar utilizar um número diferente de valores 'Y' acima. (Versões anteriores à versão 3.22.11 tem menos campos de privilégios, e posteriores a 4.02 têm mais). Para o utilizador admin, a maior sintaxe legível de INSERT usando SET que está disponível a partir da versão 3.22.11 é a utilizada.
Note que para configurar um superutilizador, você só precisar criar uma entrada na tabela user com os campos de privilégios configurados para 'Y'. Não é necessário gerar entradas nas tabelas db ou host.
Na última instrução INSERT (para o utilizador dummy), apenas as colunas Host, User e Password nos registros da tabela user tem valores atribuídos. Nenhuma das colunas de privilégios são definidas explicitamente, assim o MySQL atribui a todas o valor padrão de 'N'. Isto é a mesma coisa que o GRANT USAGE faz.
O seguinte exemplo adiciona um utilizador custom que pode acessar o banco de dados bankaccout apenas do localhost, o banco de dados expenses somente de whitehouse.gov e o banco de dados customer de todas de server.domain. Ele deseja utilizar a senha obscure das três máquinas.
Para configurar os privilégios deste utilizador utilizando instruções GRANT, execute estes comandos:
-> TO custom@'whitehouse.gov'
-> TO custom@'server.domain'
Para configurar os privilégios do utilizador modificiando as tabelas de permissões diretamente, utilize estes comandos (perceba o FLUSH PRIVILEGES no final):
-> VALUES('server.domain','customer','custom','Y','Y','Y','Y','Y','Y');
Como no exemplo anterior que usaram as instruções INSERT, você pode precisar de usar um número diferentes de valores 'Y', dependendo de sua versão do MySQL.
As primeiras três instruções INSERT adicionam entradas na tabela user que permite ao utilizador custom conectar a partir de várias máquinas com a senha determinada, mas não concede permissões ao mesmo (todos os privilégios são configurados com o valor padrão de 'N'). As próximas três instruções INSERT adicionam entradas na tabela db que concedem privilégios à custom para os bancos de dados bankaccount, expenses e customer, mas só quando acessados à partir das máquinas apropriadas. Normalmente, depois de modificar as tabelas de permissões diretamente, você deve dizer ao servidor para recarregá-las (com FLUSH PRIVILEGES) para que as alterações nos privilégios tenham efeito.
Se você deseja fornecer a um utilizador específico acesso de qualquer máquina em um determinado domínio (por exemplo, meudomínio.com), você pode utilizar uma instrução GRANT como a seguir:
-> TO myusername@'%.mydomain.com'
Para realizar a mesma coisa modificando diretamente as tabelas de permissões, faça isto:
mysql> INSERT INTO user VALUES ('%.meudominio, 'meunomedeusuario'
PASSWORD('minhasenha'),...);
DROP USER nome_usuario
Este comando foi adicionado ao MySQL 4.1.1.
Ele apaga um utilizador que não possua nenhum privilágio.
Para deletar um utilizador do MySQL você usar o seguinte procedimento, realizando os passos na ordem mostrada.
Verifique quais privilégios o utilizador tem com SHOW PRIVILEGES. Veja mais informações sobre isto na Seção 4.6.8.11, "SHOW PRIVILEGES".
Delete todos os privilégios do utilizador com REVOKE. Veja mais informações sobre isto na Seção 4.4.1, "A Sintaxe de GRANT e REVOKE".
Delete o utilizador com DROP USER.
Se você estiver usando uma versão mais antiga do MySQL você deve primeiro revogar os privilégios e então deletar o utilizador com:
DELETE FROM mysql.user WHERE user='username' and host='hostname';
A partir do MySQL 4.0.2 pode se limitar certos recursos por utilizadores.
Até então, o único método disponível de limitação de uso do servidor MySQL era canfigurar a variável de inicialização max_user_connections para um valor diferente de zero. Mas este método é estritamente global e não permite o gerenciamento de utilizadores individuais, o que pode ser de interresse particular do Provedor de Serviços Internet.
Consequentemente, o gerenciamento de três recursos é introduzido no nível de utilizador individual:
Número de todas as consultas por hora: Todos os comandos que podiam ser executados por um utilizador.
Número de todas as atualizações por hora: Qualquer comando que altera qualquer tabela ou banco de dados.
Númeor de conexões feitas por hora: Novas conexões abertas por hora.
Um utilizador no contexto mencionado acima é uma única entrada na tabela user, que é identificada unicamente por suas colunas user e host.
Todos os utilizadores não são limitados por padrão no uso dos recursos acima, a menos que os limites sejam garantidos a eles. Estes limites podem ser concedidos apenas através do GRANT (*.*) global, usando esta sintaxe:
Pode-se especificar qualquer combinação dos recursos acima. N1, N2 e N3 são inteiros e significam contagem/hora.
Se os utilizadores alcançam o limite de conexões dentro de uma hora, não será aceita mais nenhuma conexão até o fim desta hora. De forma parecida se o utilizador alcança o limite do número de consultas ou atualizações, consultas ou atualizações adicionais serão rejeitadas até que a hora acabe. Em todos os casos, uma mensagem de erro apropriada é enviada.
Os valores atualmente usados por um utilizador em particular pode ser descarregados (zerados) enviando uma instrução GRANT com qualquer das cláusulas acima, incluíndo uma instrução GRANT com os valores atuais.
Os valores atuais para todos os utilizadores para todos os utilizadores serão descarregados se os privilégios forem recarregados (no servidor ou usando mysqladmin reload) ou se o comando FLUSH USER_RESOURCES é executado.
O resurso está habilitado assim que e concedido a um único utilizador qualquer das cláusulas GRANT de limitação.
Como um prerequisito para a habilitação deste recurso, a tabela user no banco de dados mysql deve conter as colunas adicionais, como definido no script de criação de tabelas mysql_install_db e mysql_install_db.sh no subdiretório scripts.
Na maioria dos casos você deve utilizar GRANT para configurar seus utilizadores e senhas, portanto, as informações exibidas a seguir são aplicadas somentes para utilizadores avançados. Veja mais informações sobre isto na Seção 4.4.1, "A Sintaxe de GRANT e REVOKE".
Os exemplos nas seções precedentes ilustram um princípio importante: quando você armazena uma senha não-vazia utilizando INSERT ou UPDATE você deve utilizar a função PASSWORD() para criptografá-la. Isto é porque a tabela user armazena senhas na forma criptografada, e não como texto puro. Se você esquecer deste fato, é provável que você possa tentar configurar senhas desta forma:
O resultado é que o valor 'biscuit' é armazenado como a senha na tabela user. Quando o utilizador jeffrey tentar se conectar ao servidor utilizando esta senha, o cliente mysql a criptografa utilizando a função PASSWORD(), gerando um vetor de autenticação baseado em uma senha criptografada e um número randômico, obtido do servidor, e envia o resultado ao servidor. O servidor usa o valor do campo password na tabela user (que é o valor 'biscuit' não criptografado ) para realizar os mesmos cálculos e comparar os resultados. A comparação falha e o servidor rejeita a conexão:
As senhas devem ser criptografadas quando elas são inseridas na tabela user, portanto a instrução INSERT deveria ter sido informada no seguinte formato:
Você deve também utilizar a função PASSWORD() quando utilizar instruções SET PASSWORD:
Se você configurar senhas utilizando a instrução GRANT ... IDENTIFIED BY ou o comando mysqladmin password, a função PASSWORD() é desnecessária. Ambos tomam o cuidado de criptografar a senha para você, então você deve especificar a senha 'biscuit' desta forma:
NOTA: PASSWORD() é diferente da senha criptografada do Unix.
Não é aconselhável especificar uma senha de uma forma que a exponha e possa ser descoberta por outros utilizadores. Os métodos que você pode usar para especificar sua senha quando executar programas clientes são listados abaixo, juntamente com as determinações de riscos de cada método:
Nunca forneça a um utilizador normal acesso à tabela mysql.user. O conhecimento de uma senha criptografada possibilita a conexão como este utilizador. As senhas só estão embaralhadas para que não seja possível chegar à senha real que foi usada (acontece muito a utilização de senhas similares em outras aplicações).
Uso da opção -psua_senha ou --password=sua_senha na linha de comando. Isto é conveniente mas inseguro, porque sua senha se torna visível para programas de informação do sistema (como no ps) que pode ser chamado por outros utilizadores para exibir linhas de comando. (clientes MySQL normalmente gravam zeros em cima do argumento da linha de comando durante sua sequência de inicialização, mas ainda existe um breve intervalo no qual o valor está visível.)
Uso das opções -p ou --pasword (sem especificar o valor sua_senha). Neste caso, o programa cliente solicita a senha do terminal:
Os caracteres '*' representam sua senha.
É mais seguro digitar sua senha desta forma do que especificá-la na linha de comando porque ela não fica visível a outros utilizadores. Entretanto este método de digitar uma senha é válido somente para programas que você executa de forma interativa. Se você deseja chamar um cliente de um script que não execute interativamente, não existirá oportunidade de digitar a senha do terminal. Em alguns sistemas, você pode descobrir que a primeira linha do seu script é lida e interpretada (incorretamente) como sua senha!
Armazenar a sua senha em um arquivo de configuração. Por exemplo, você pode listar sua senha na seção [client] do arquivo .my.cnf no seu diretório home:
Se você armazenar sua senha em um arquivo .my.cnf, o arquivo não pode ser lido por seu grupo ou pelos outros utilizadores. Tenha certeza que o modo de acesso do arquivo é 400 ou 600 Veja mais informações sobre isto na Seção 4.1.2, "Arquivo de Opções my.cnf".
Você pode armazenar sua senha na variável de ambiente MYSQL_PWD, mas este método deve ser considerado extremamente inseguro e não deve ser usado. Algumas versões de ps incluem uma opção para exibir o ambiente de processos em execução; sua senha estaria em texto puro para a leitura para todos os utilizadores. Mesmo em sistemas sem esta versão do ps, seria imprudência assumir que não existe outro método para observar o ambiente de processos. Veja mais informações sobre isto na Apêndice F, Variáveis de Ambientes do MySQL.
Em resumo, os métodos mais seguros seriam que o programa cliente solicitasse a senha ou especificar a senha em um arquivo .my.cnf corretamente protegido.
4.4.10.1. Conceitos Basicos
A partir da versão 4.0.0, o MySQL tem suporte a conexões cri[ptografadas com SSL. Para entender como o MySQL usa SSL, é necessário explicar alguns conceits básicos de SSL e X509. A pessoal que já estão familiarizada com eles podem saltar esta parte.
Por padrão o MySQL não usa conexões criptografadas entre o cliente e o servidor. Isto significa que qualquer um pode observar todo o tráfico e ver os dados enviados e recebidos. Podiase até mesmo alterar os dados enquanto eles estavam em transito entre o cliente e o servidor. Algumas vezes você precisao mover informações sobre redes públicas de um modo seguro; em tais casos, usar uma conexão sem criptografia é inaceitável.
SSL é um protocolo que utiliza diferentes algorítimos de criptografia para assegurar que os dados recebidos por uma rede pública são confiáveis. Ele tem um mecanismo para detectar qualquer alteração, perda ou reenvio de dados. SSL também incorpora algoritmos para reconhecer e fornecer identidades de verificação usando o padrão X509.
Criptografia é o modo de tornar qualquer tipo de dado ilegível. De fato, as práticas de hoje precisam de muitos elementos de segurança adicionais para algoritmos de criptografia. Eles devem resistir a muitos tipos de atques conhecidos como apenas alterando a ordem da mensagem criptografada ou emviando o dado duas vezes.
X509 é um padrão que torna possível identificar alguém na Internet. Ele é mais comumente usado em aplicações e-commerce. Em termos básicos, deve haver algumas empresas (chamadas ``Autoridades de Certificação'') que atribuem certificados eletrônicos para qualquer um que precise deles. Os certificados se baseiam em algorítmos de criptografia assimétricos que possuem duas chaves de criptografia (uma chave pública e uma chave secreta). Um proprietário de certificado pode provar a sua identidade mostrnado este certificado para outra parte. Um certificado consiste das chaves públicas do proprietário. Qualquer dados criptografado com esta chave pública pode ser descriptografada apenas usando a chave secreta correspondente, que é guardada pelo dono do certificado.
O MySQL não utiliza conexões criptografadas por padrão, porque fazendo isto tornaria o protocolo cliente/servidor muito lento. Qualquer tipo de funcionalidade adiocional exige que o conputador faça um trabalho adicional e a criptografia de dados é uma operação intensiva da CPU que exige tempo e pode atrasar o MySQL nas tarefas principais. Por padrão o MySQL é ajustado para ser o mais rápido possível.
Se você precisa de mais informações sobre SSL, X509 ou criptografia, você deve usar se mecanismo de busca favorita na Internet para procurar sobre o assunto que está interessado.
4.4.10.2. Exigências
Para conseguir conexões seguras para trabalhar com o MySQL você deve fazer o seguinte:
Insatale o biblioteca OpenSSL. Testamos o MySQL com OpenSSL 0.9.6. http://www.openssl.org/.
Configure o MySQL com --with-vio --with-openssl.
Se você estiver usando um instalação antiga do MySQL, você tem que atualizar a sua tabela mysql.user com algumas novas colunas relacionadas a SSL. Isto é necessário se suas tabelas de permissões são de uma versão anterior ao MySQL 4.0.0. O procedimento está descrito em Seção 2.5.6, "Atualizando a Tabela de Permissões".
Você pode verificar se um servidor mysqld em execução suporta OpenSSL examinando se SHOW VARIABLES LIKE 'have_openssl' retorna YES.
4.4.10.3. Configurando Certificados SSL para o MySQL
Aqui está um exemplo para configurar certificados SSL para o MySQL:
# Crie os aarquivos necessário: $database, $serial e o diretório
$new_certs_dir (opcional)
# Geração do Certificate Authority(CA)
# Saída exemplo:
# Assina o certificado do servidor
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MySQL AB'
# commonName :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT (365 days)
# commonName :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT (365 days)
# To test MySQL
mysqld --defaults-file=$DIR/my.cnf &
mysql --defaults-file=$DIR/my.cnf
Você também pode testar sua configuração modificando o arquivo my.cnf acima para fazer referência aos certificados de demonstração no diretório mysql-dist-fonte/SSL.
4.4.10.4. Opções SSL do GRANT
O MySQL pode verificar atributos do certificado X509 em adição ao esquema normal de utilizador/senha. Todas as opções comuns ainda são exigidas (utilizador, senha, máscara do endereço IP, noome tabela/banco de dados).
Existem diferentes possibilidades para limitarmos as conexões:
Sem nenhuma opção SSL ou X509, todos os tipos de conexões criptografadas/ descriptografadas são permitidas se o utilizador e senha são válidos.
A opção REQUIRE SSL limita o servidor para permitir apenas conexões criptografadas SSL. Note que esta opção pode ser omitida se não houver nenhum registro ACL que permita conexões não SSL.
REQUIRE X509 significa que o cliente deve ter um certificado válido mas não nos procupamos sobre o certificado, o emissor ou assunto exato. A única restrição é que deve ser possível verificar a sua assinatura com um dos certificados CA.
REQUIRE ISSUER 'emissor' coloca uma restrição na tentativa de conexão: O cliente deve apresentar um certificado X509 válido emitido pelo CA 'emissor'. Usar o certificado X509 sempre implica em criptografia, assim a opção SSL é desnecessária.
-> REQUIRE ISSUER 'C=FI, ST=Some-State, L=Helsinki,
'> O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com';
REQUIRE SUBJECT 'assunto' exige que o cliente tenha um certificado X509 com o assunto 'assunto'. Se o cliente apresenta um certificado que é valido mas tem um 'assunto' diferente, a conexão é disabilitada.
-> REQUIRE SUBJECT 'C=EE, ST=Some-State, L=Tallinn,
'> O=MySQL demo client certificate,
'> CN=Tonu Samuel/Email=tonu@mysql.com';
REQUIRE CIPHER 'método' é necessário para assegurar que uma criptografia forte será usada. O SSL pode ser fraco se algoritmos antigos com chaves de criptografias curtas são usados. Usando esta opção, podemos pedir por algum método de criptografia exato para permitir a conexão.
As opções SUBJECT, ISSUER e CIPHER podem ser combinadas na cláusula REQUIRE desta forma:
'> CN=Tonu Samuel/Email=tonu@mysql.com'
-> AND ISSUER 'C=FI, ST=Some-State, L=Helsinki,
'> O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com'
A partir do MySQL 4.0 a palavra chave AND é opcional entre opções REQUIRE.
A ordem das opções não importa, mas nenhuma opção pode ser especificada duas vezes.
4.4.10.5. Opções SSL de Linha de Comando
A seguinte tabela lista opções que são usadas para especificar o uso de SSL, arquivos de certificado e arquivos de chaves. Estas opções estão disponíveis a partir do MySQL 4.0. Elas podem ser dadas na linha de comando ou no arquivo de opção.
Para o servidor, especifica que o servidor permite conexões SSL. Para um programa cliente, permite que o cliente se conecte ao servidor usando SSL. Esta opção por si só não é suficiente para fazer uma conexão SSL ser usada. Você também deve especificar as opções --ssl-ca, --ssl-cert, e --ssl-key.
Note que esta opção não exige uma conexão SSL. Por exemplo, se o servidor ou clienteestá compilado sem suporte SSL, uma conexão não criptografada normal será usada.
O modo seguro de de se certificar que uma conexão SSL será usada é criar uma conta no servidor que inclua uma cláusula REQUIRE SSL na instrução GRANT. Então use esta conta para se conectar ao servidor, com um servidor e cliente que tenham suporte a SSL habilitado.
Você pode usar esta opção para indicar que a conexão não deve usar SSL. Faça isto especificando a opção como --skip-ssl ou --ssl=0.
O caminho para um arquivo vom uma lista de Certifcados SSL confiáveis.
O caminho para um diretório que contém certificados SSL confiáveis no formato pem.
O nome do arquivo de certificado SSL usado para estabelecer uma conexão segura.
Uma lista de chaves permitidas, usado para criptografia SSL. cipher_list tem o mesmo formato que o comando openssl ciphers.