Como o Sistema de Privilégios Funciona

O sistema de privilégios do MariaDB garante que todos usuários possam fazer exatamente as operações que lhe é permitido. Quando você conecta a um servidor MySQL, sua identidade é determinada pela maquina de onde você conectou e o nome de usuário que você especificou. O sistema concede privilégios de acordo com sua identidade e com o que você deseja fazer.

O MariaDB considera tanto os nomes de máquinas como os nomes de usuários porque existem poucas razões para assumir que um determinado nome de usuário pertence a mesma pessoa em todo lugar na Internet. Por exemplo, o usuário bill que conecta de whitehouse.gov não deve necessariamente ser a mesma pessoa que o usuário bill que conecta da microsoft.com O MariaDB lida com isto, permitindo a distinção de usuários em diferentes máquinas que podem ter o mesmo nome: Você pode conceder a bill um conjunto de privilégios para conexões de whitehouse.gov e um conjunto diferente de privilégios para conexões de microsoft.com.

O controle de acesso do MariaDB é composto de dois estágios:

• Estágio 1: O servidor confere se você pode ter acesso ou não.
• Estágio 2: Assumindo que você pode conectar, o servidor verifica cada requisição feita para saber se você tem ou não privilégios suficientes para realizar a operação. Por exemplo, se você tentar selecionar linha de uma tabela em um banco de dados ou apagar uma tabela do banco de dados, o servidor se certifica que você tem o privilégio select para a tabela ou o privilégio drop para o banco de dados.

Note que se os seus privilégios são alterados (tanto por você quanto por outro) enquanto você está conectado, estas alterações não irão necessariamente ter efeito com a sus próxima consulta ou consultas. Veja "Quando as Alterações nos Privilégios tem Efeito" para maiores detalhes.

O servidor utiliza as tabelas user, db e host no banco de dados MariaDB em ambos estágios do controle de acesso. Os campos nestas tabelas de permissão são detalhados abaixo:

Nome da Tabela	user	db	host
Campos de Escopo	Host	Host	Host
	User	Db	Db
	Password	User
Campos de Privilégio	Select_priv	Select_priv	Select_priv
	Insert_priv	Insert_priv	Insert_priv
	Update_priv	Update_priv	Update_priv
	Delete_priv	Delete_priv	Delete_priv
	Index_priv	Index_priv	Index_priv
	Alter_priv	Alter_priv	Alter_priv
	Create_priv	Create_priv	Create_priv
	Drop_priv	Drop_priv	Drop_priv
	Grant_priv	Grant_priv	Grant_priv
	References_priv	References_priv	References_priv
	Reload_priv
	Shutdown_priv
	Process_priv
	File_priv
	Show_db_priv
	Super_priv
	Create_tmp_table_priv	Create_tmp_table_priv	Create_tmp_table_priv
	Lock_tables_priv	Lock_tables_priv	Lock_tables_priv
	Execute_priv
	Repl_slave_priv
	Repl_client_priv
	ssl_type
	ssl_cypher
	x509_issuer
	x509_cubject
	max_questions
	max_updates
	max_connections

No segundo estágio do controle de acesso (verificação da solicitação), o servidor pode, se a solicitação involver tabelas, consultar adicionalmente as tabelas tables_priv e columns_priv. Os campos nestas tabelas são mostrados abaixo:

Nome da tabela	tables_priv	columns_priv
Campos de escopop	Host	Host
	Db	Db
	User	User
	Table_name	Table_name
		Column_name
Campos de privilégio	Table_priv	Column_priv
	Column_priv
Outros campos	Timestamp	Timestamp
	Grantor

Cada tabela de permissões contêm campos de escopo e campos de privilégios.

Campos de escopo determinam o escopo de cada entrada nas tabelas, isto é, o contexto no qual a entrada se aplica. Por exemplo, uma entrada na tabela user com valores Host e User de 'thomas.loc.gov' e 'bob' devem ser usados para autenticar conexões feitas ao servidor por bob da máquina thomas.loc.gov. De maneira similar, uma entrada na tabela db com campos Host, User e Db de 'thomas.loc.gov', 'bob' e 'reports' devem ser usados quando bob conecta da máquina thomas.loc.gov para acessar o banco de dados reports. As tabelas tables_priv e columns_priv contem campos de escopo indicando as combinações de tabelas ou tabela/coluna para o qual cada entrada se aplica.

Para propósitos de verificação de acessos, comparações de valores Host são caso insensitivo, valores User, Password, Db e Table_name são caso sensitivo. Valores Column_name são caso insensitivo no MariaDB versão 3.22.12 ou posterior.

Campos de privilégios indicam os privilégios concedidos por uma entrada na tabela, isto é, quais operações podem ser realizadas. O servidor combina as informações de várias tabelas de concessão para formar uma descrição completa dos privilégios de um usuário. As regras usadas para fazer isto são descritas em "Controle de Acesso, Estágio 2: Verificação da Requisição".

Campos de escopo são strings, declaradas como mostrado abaixo; os valores padrão para cada é a string vazia:

Nome do Campo	Tipo
Host	CHAR(60)
User	CHAR(16)
Password	CHAR(16)
Db	CHAR(64)	(CHAR(60) para as tabelas tables_priv e columns_priv)
Table_name	CHAR(60)
Column_name	CHAR(60)

Nas tabelas user, db e host, todos campos de privilégios são declarados como ENUM('N','Y') --- cada um pode ter um valor de 'N' ou 'Y' e o valor padrão é 'N'.

Nas tabelas tables_ e columns_priv, os campos de privilégios são declarados como campos SET:

Nome de tabela	Nome do campo	Possíveis elementos do conjunto
tables_priv	Table_priv	'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_priv	Column_priv	'Select', 'Insert', 'Update', 'References'
columns_priv	Column_priv	'Select', 'Insert', 'Update', 'References'

De maneira resumida, o servidor utiliza as tabelas de permissões desta forma:

• Os campos de escopo da tabela user determinam quando permitir ou aceitar conexões. Para conexões permitidas, qualquer privilégio concedido em uma tabela user indica o privilégio global (superusuário) do usuário. Estes privilégios se aplicam a todos os bancos de dados no servidor.
• As tabelas db e host são usadas juntas:
  
  
  • Os campos de escopo da tabela db determinam quais usuários podem acessar determinados bancos de dados de máquinas determinadas. Os campos de privilégios determinam quais operações são permitidas.
  • A tabela host é usada como uma extensão da tabela db quando você quer que uma certa entrada na tabela db seja aplicada a diversas máquinas. Por exemplo, se você deseja que um usuário esteja apto a usar um banco de dados a partir de diversas máquinas em sua rede, deixe o campo Host vazio no registro da tabela db, então popule a tabela Host com uma entrada para cada uma das máquinas. Este mecanismo é descrito com mais detalhes em "Controle de Acesso, Estágio 2: Verificação da Requisição".
• As tabelas tables_priv e columns_priv são similares à tabela db, porém são mais finas: Elas se aplicam ao nível de tabelas e colunas em vez do nível dos bancos de dados.

Perceba que os privilégios administrativos (RELOAD, SHUTDOWN e etc) são especificados somente na tabela user. Isto ocorre porque operações administrativas são operações no próprio servidor e não são específicas e não específicas dos bancos de dados, portanto não existe razão para listar tais privilégios nas outras tabelas de permissão. De fato, somente a tabela user necessita ser consultada para determinar se você pode ou não realizar uma operação administrativa.

O privilégio FILE também só é especificado na tabela user. Ele não é um privilégio administrativo, mas sua habilidade para ler ou escrever arquivo no servidor é independtende do banco de dados que você está acessando.

O servidor mysqld le o conteúdo das tabelas de permissões uma vez, quando é iniciado. Alterações nas tabelas de permissões tem efeito como indicado em "Quando as Alterações nos Privilégios tem Efeito".

Quando você modifica o conteúdo das tabelas de permissões, é uma boa idéia ter certeza que suas alterações configuraram os privilégios da forma desejada. Para ajuda no diagnostico de problemas, veja "Causas dos Erros de Accesso Negado". Para conselhos sobre asssuntos de segurança, Leia "Como Tornar o MariaDB Seguro contra Crackers".

Uma ferramenta de diagnóstico útil é o script mysqlaccess, que Yves Carlier fornece na distribuição MariaDB. Chame mysqlaccess com a opção --help para descobrir como ele funciona. Perceba que o mysqlaccess confere o acesso usando somente as tabelas user, db e host. Ele não confere privilégios no nível de tabelas ou colunas.

Retornar