Controle de Acesso, Estágio 2: Verificação da Requisição


Uma vez estabelecida uma conexão, o servidor entra no 2o estágio. Para cada requisição que vem na conexão, o servidor verifica se você tem privilégios suficientes para realizá-la, baseado nas operações que você deseja fazer. É aqui que os campos de concessões nas tabelas de permissões entram em ação. Estes privilégios pode vir de qualquer uma das tabelas user, db, host, tables_priv ou columns_priv. As tabelas de permissões são manipuladas com os comandos GRANT e REVOKE. Leia "A Sintaxe de GRANT e REVOKE". (Você pode achar útil fazer referencia a "Como o Sistema de Privilégios Funciona", que lista os campos presentes em cada uma das tabelas de permissões.)

A tabela user concede privilégios que são especificados por você em uma base global e que se aplicam sem importar qual é o banco de dados atual. Por exemplo, se a tabela user concede a alguém o privilégio delete, este usuário pode apagar linhas de qualquer banco de dados no servidor! Em outras palavras, privilégios na tabela user são privilégios de superusuário. O correto é conceder privilégios na tabela user apenas para superusuários tais como os administradores de servidor ou de bancos de dados. Para outros usuários, você deve deixar os privilégios na tabela user configurados para 'N' e conceder privilégios somente em bancos de dados específicos, utilizando as tabelas db e host.

As tabelas db e host concedem privilégios para bancos de dados específicos. Valores nos campos de escopo podem ser especificados como a seguir:

As tabelas db e host são lidas e ordenadas quando o servidor inicia (ao mesmo tempo que ele lê a tabela user). A tabela db é ordenada nos campos de escopo Host, Db e User e a tabela host é ordenada nos campos de escopo Host e Db. Assim como na tabela user, a ordenação coloca os valores mais específicos no início e os menos específicos por último, e quando o servidor procura por entradas coincidentes, ele usa a primeira combinação que encontrar.

As tabelas tables_priv e columns_priv concedem privilégios específicos para tabelas e campos. Valores nos campos escopo podem ser especificados como a seguir:

As tabelas tables_priv e columns_priv são ordenadas nos campos Host, DB e User. Isto é parecido com a ordenação da tabela db, no entanto, a ordenação é mais simples porque somente o campo Host pode conter meta caracteres.

O processo de verificação da requisição é descrito abaixo. (Se você já está familiarizado com o código de verificação de acesso, você irá perceber que a descrição aqui é um pouco diferente do algorítimo usado no código. A descrição é equivalente ao que o código realmente faz; ele só é diferente para tornar a explicação mais simples.)

Para requisições administrativas (SHUTDOWN, RELOAD, etc.), o servidor confere somente a entrada da tabela user, porque ela é a única tabela que especifica privilégios administrativos. O acesso é concedido se o registro permitir a operação requisitada ou negado caso o contrário. Por exemplo, se você deseja executar mysqladmin shutdown mas a entrada em sua tabela user não lhe concede o privilégio SHUTDOWN, o acesso é negado mesmo sem consultar as tabelas db ou host. (elas não contém o campo Shutdown_priv, portanto não existe esta necessidade.)

Para requisições relacionadas aos bancos de dados (insert, udpdate, etc.), o servidor primeiro confere os privilégios globais do usuário consultando as entradas da tabela user. Se a entrada permitir a operação requisitada, o acesso é concedido. Se os privilégios globais na tabela user são insuficientes, o servidor determina os privilégios específicos de banco de dados para o usuário consultando as tabelas db e host:

  1. O servidor consulta a tabela db por uma combinação nos campos Host, Db e User. Os campos Host e User são comparados com o nome da máquina e o nome do usuário que faz a requisição. O campo Db é comparado com o banco de dados que o usuário deseja acessar. Se não existir entradas coincidentes para o Host e User, o acesso é negado.
  2. Se existir uma combincação com a entrada da tabela db e seu campo Host não estiver em branco, aquela entrada define os privilégios especificos do banco de dados do usuario.
  3. Se o registro coincidente da tabela db tiver o campo Host em branco, significa que a tabela host enumera quais máquinas são permitidas acessar o banco de dados. Neste caso, uma consulta adicional é feita na tabela host para encontrar uma valores coincidentes nos campos Host e Db. Se nenhuma entrada na tabela host coincide, o acesso é negado. Se existir uma coincidência, os privilégios específicos de bancos de dados para o usuário são computados como a interseção (não a união!) dos privilégios nas entradas das tabelas db e host, isto é, os privilégios que são 'Y' em ambas entradas. (Desta forma você pode conceder privilégios gerais em entradas na tabela db e então restringi-los em uma base de máquina a máquina utilizando as entradas da tabela host.)

Depois de determinar os privilégios específicos do banco de dados concedido pelas entradas nas tabelas db e host, o servidor os adiciona aos privilégios globais concedidos pela tabela user. Se o resultado permitir a operação requisitada, o acesso será concedido. De outra forma, o servidor consulta os privilégios de tabelas e campos do usuario nas tabelas tables_priv e columns_priv e os adiciona aos privilégios do usuário. O acesso será permitido ou negado baseado no resultado.

Expresso em termos booleanos, a descrição precedente de como os privilégios de um usuário são calculados podem ser resumido assim: 

global privileges OR (database privileges AND host privileges)
OR table privileges OR column privileges

Ele pode não ser aparente porque, se os privilégios da entrada global de user são inicialmente insuficientes para a operação requisitada, o servidor adiciona estes privilégios mais tarde aos privilégios específicos de banco de dados, tabelas e colunas. A razão é que uma requisição pode exigir mais que um tipo de privilégio. Por exemplo, se você executar uma instrução INSERT ... SELECT, você precisa dos privilégios INSERT e SELECT. Seu privilégio pode ser tal que a entrada da tabela user concede um privilégio e a entrada da tabela db concede o outro. Neste caso, você tem os privilégios necessários para realizar a requisição, mas o servidor não pode obtê-los de ambas as tabelas por si próprio; os privilégios concedidos pelas entradas em ambas as tabelas de ser combinados.

A tabela host pode ser usada para manter uma lista dos servidores seguros.

Na Tcx, a tabela host contém uma lista de todas as máquina na rede local. A elas são concedidos todos os privilégios.

Você pode também usar a tabela host para indicar máquinas que não são seguras. Suponha que você tenha uma máquina public.your.domain que está localizada em uma área pública que você não considera segura. Você pode permitir o acesso a todas as máquinas de sua rede exceto a esta máquina usando entradas na tabela host desta forma: 

+--------------------+----+-
| Host | Db | ...
+--------------------+----+-
| public.your.domain | % | ... (todos os privilégios configurados para 'N')
| %.your.domain | % | ... (todos os privilégios configurados para 'Y')
+--------------------+----+-

Naturalmente, você deve sempre testar suas entradas nas tabelas de permissões (por exemplo, usar o mysqlaccess para ter certeza que os privilégios de acesso estão atualmente configurados da forma que você imagina.

Retornar