Usuários e permissões

Uma conexão aceita pelo MySQL ainda não garante que a operação seja permitida. O sistema pode abrir normalmente e receber uma recusa ao gravar uma venda, ou um técnico pode precisar consultar o banco sem nenhum risco de alterar os dados. As contas e as permissões explicam essas situações e indicam como acessar o banco com segurança.

Quem é a conta e o que ela pode fazer

O MySQL trata o acesso em duas etapas:

• Autenticação: o MySQL confere quem está se conectando, pelo usuário, pela senha e pelo computador de origem.
• Autorização: o MySQL confere o que essa conta pode fazer, a cada comando recebido.

Uma conta é formada pelo nome do usuário e pela origem, no formato 'usuario'@'origem'. A conta 'sistema'@'192.168.1.%', por exemplo, representa o usuário sistema conectado a partir de qualquer computador da rede da loja.

Quando o MySQL recebe uma conexão, o servidor escolhe a conta mais específica que corresponde ao usuário e à origem. Por isso, a conta usada nem sempre é a que se espera. Dois comandos mostram essa diferença:

• SELECT USER();: mostra o usuário e o computador informados na conexão;
• SELECT CURRENT_USER();: mostra a conta que o MySQL escolheu e cujas permissões está aplicando.

As permissões

As permissões, chamadas de privilégios, definem os comandos que cada conta pode executar. Os mais comuns são:

• SELECT: consultar dados;
• INSERT: incluir linhas;
• UPDATE: alterar linhas;
• DELETE: apagar linhas;
• CREATE, ALTER e DROP: criar, alterar e apagar tabelas e outras estruturas;
• PROCESS: ver as conexões de todas as contas.

Cada privilégio vale em um nível: no servidor inteiro, em um banco, em uma tabela ou em uma coluna. Na notação do MySQL, loja.* significa todas as tabelas do banco loja, e loja.vendas significa apenas a tabela vendas.

O privilégio PROCESS tem um efeito comum no suporte. Sem esse privilégio, o comando SHOW PROCESSLIST mostra apenas as conexões da própria conta, e uma conexão de outro usuário que esteja travando a tabela fica invisível.

Como consultar e conceder permissões

• SHOW GRANTS;: mostra as permissões da conta em uso;
• SHOW GRANTS FOR 'sistema'@'192.168.1.%';: mostra as permissões de outra conta, quando a conta em uso tem acesso a essa informação;
• SELECT user, host FROM mysql.user;: lista as contas cadastradas no servidor, quando a conta em uso tem acesso a essa tabela interna.

A criação de contas e a concessão de permissões seguem o procedimento da empresa, porque o sistema depende das contas existentes. Os comandos envolvidos são:

• CREATE USER 'consulta'@'192.168.1.%' IDENTIFIED BY 'senha';: cria a conta, e a palavra senha representa a senha definida pela equipe;
• GRANT SELECT ON loja.* TO 'consulta'@'192.168.1.%';: concede à conta a permissão de consultar todas as tabelas do banco loja;
• REVOKE SELECT ON loja.* FROM 'consulta'@'192.168.1.%';: retira essa permissão.

No MySQL 8, a conta precisa existir antes do GRANT. Nas versões anteriores, o próprio GRANT podia criar a conta. O servidor carrega as mudanças de permissão imediatamente, mas uma conexão já aberta pode precisar ser refeita para que algumas mudanças passem a valer. O comando FLUSH PRIVILEGES só é necessário quando as tabelas internas de permissões são alteradas diretamente, o que não é recomendado.

Uma conta só de leitura para o atendimento

Uma conta com o privilégio SELECT e nenhum outro consegue consultar os dados, mas não consegue alterá-los nem apagá-los. Para as consultas do atendimento, essa conta reduz o risco de um comando digitado por engano mudar dados reais. A conta do sistema, ao contrário, costuma ter permissões de gravação. A conta root, criada na instalação, tem todas as permissões e não deve ser usada nas consultas do dia a dia.

Os erros de permissão

Quando a conta não tem a permissão necessária, o MySQL responde com erros próprios, diferentes do erro de senha:

• Acesso negado ao banco, código 1044: a conta não tem permissão para usar o banco indicado;
• Comando negado na tabela, código 1142: a conta não tem a permissão exigida pelo comando naquela tabela, como INSERT na tabela vendas;
• Operação administrativa negada, código 1227: o comando exige um privilégio administrativo que a conta não tem.

Esses erros mostram que a conexão e a identificação funcionaram. O problema está na autorização, e a investigação segue para as permissões da conta que o MySQL escolheu.

O método de autenticação e a versão do cliente

O MySQL 8 adotou um método de autenticação mais seguro como padrão, chamado caching_sha2_password. Programas e bibliotecas antigos, feitos para as versões anteriores, podem não conhecer esse método e falhar ao conectar, com mensagens como a de plugin de autenticação que não pôde ser carregado, código 2059. Nesses casos, a solução depende de atualizar o componente de conexão do programa ou de ajustar o método da conta, conforme o procedimento da equipe.

O caminho inverso também acontece. Em servidores antigos, como os da versão 5.1, uma conta com a senha gravada no formato anterior ao MySQL 4.1 é recusada pelos programas atuais, com o erro de protocolo de autenticação antigo, código 2049. Nesse caso, a solução passa por gravar a senha da conta no formato novo, conforme o procedimento da equipe.

A senha da conta do sistema também costuma estar gravada na configuração de cada estação. Depois de uma troca de senha no servidor, as estações que ainda usam a senha antiga passam a receber o erro de acesso negado, código 1045.