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.

