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
. See Secção 4.4.1, “A Sintaxe de GRANT
e REVOKE
”. (Você
pode achar útil fazer referencia a
Secção 4.3.6, “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:
Os metacaracteres ‘%
’ e
‘_
’ podem ser usados nos
campos Host
e Db
de
ambas tabelas. Se você deseja usar um caracter
‘_
’ como parte de um nome de
banco de dados, especifique-o como '\_
'
no comando GRANT
.
O valor '%'
em Host
na
tabela db
significa ``qualquer
máquina.'' Um valor em branco em Host
na
tabela db
significa ``consulte a tabela
host
para informação adicional.''
O valor '%'
ou em branco no campo
Host
na tabela host
significa ``qualquer máquina.''
O valor '%'
ou em branco no campo
Db
de ambas as tabelas significa
``qualquer banco de dados.''
O valor em branco no campo User
em ambas
tabelas coincide com o usuário anônimo.
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:
Os meta caracteres ‘%
’ e
‘_
’ podem ser usados no campo
Host
de ambas tabelas.
O valor '%'
ou em branco no campo
Host
em ambas tabelas significam
``qualquer máquina''
Os campos Db
,
Table_name
e
Column_name
não podem conter meta
caracteres ou serem brancos em ambas tabelas.
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
:
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.
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.
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.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.