Spec-Zone .ru
спецификации, руководства, описания, API

6.2.4. Управление доступом, Этап 1: Проверка Соединения

Когда Вы пытаетесь соединиться с сервером MySQL, сервер принимает или отклоняет соединение, основанное на Ваших идентификационных данных и можно ли проверить свои идентификационные данные, предоставляя корректный пароль. В противном случае сервер лишает доступа Вам полностью. Иначе, сервер принимает соединение, и затем вводит Этап 2 и ожидает запросов.

Ваши идентификационные данные основаны на двух сведениях:

Проверка идентификационных данных выполняется, используя три user табличные столбцы контекста (Host, User, и Password). Сервер принимает соединение только если Host и User столбцы в некоторых user соответствие строки таблицы имя хоста клиента и имя пользователя и клиент предоставляет пароль, определенный в той строке. Правила для допустимого Host и User значения даются в Разделе 6.2.3, "Определение Имен учетной записи".

Если User значение столбца является непробелом, имя пользователя во входящем соединении должно соответствовать точно. Если User значение является пробелом, оно соответствует любое имя пользователя. Если user у строки таблицы, которая соответствует входящее соединение, есть пустое имя пользователя, пользователь, как полагают, является анонимным пользователем без имени, не пользователем с именем что клиент, фактически определенный. Это означает, что пустое имя пользователя используется для всей дальнейшей проверки доступа продолжительность соединения (то есть, во время Этапа 2).

Password столбец может быть пробелом. Это не подстановочный знак и не означает, что любой пароль соответствует. Это означает, что пользователь должен соединиться, не определяя пароль. Если сервер аутентифицирует клиент, использующий плагин, метод аутентификации, что сменные реализации могут или, возможно, не используют пароль в Password столбец. В этом случае возможно, что внешний пароль также используется, чтобы аутентифицировать к серверу MySQL.

Непробел Password значения в user таблица представляет зашифрованные пароли. MySQL не хранит пароли в форме простого текста для любого, чтобы видеть. Скорее пароль, предоставленный пользователем, который пытается соединиться, шифруется (использование PASSWORD() функция). Зашифрованный пароль тогда используется во время процесса соединения, проверяя, корректен ли пароль. Это делается без зашифрованного пароля, когда-либо перемещаясь по соединению. См. Раздел 6.3.1, "Имена пользователей и Пароли".

С точки зрения MySQL зашифрованный пароль является реальным паролем, таким образом, никогда недопустимо предоставлять никому доступ к этому. В частности не давайте неадминистративный пользовательский доступ для чтения к таблицам в mysql база данных.

Следующая таблица показывает как различные комбинации Host и User значения в user таблица применяется к входящим соединениям.

Host Значение User Значение Допустимые Соединения
'thomas.loc.gov' 'fred' fred, соединение от thomas.loc.gov
'thomas.loc.gov' '' Любой пользователь, соединяющийся от thomas.loc.gov
'%' 'fred' fred, соединение от любого узла
'%' '' Любой пользователь, соединяющийся от любого узла
'%.loc.gov' 'fred' fred, соединение от любого узла в loc.gov домен
'x.y.%' 'fred' fred, соединение от x.y.net, x.y.com, x.y.edu, и так далее; это, вероятно, не полезно
'144.155.166.177' 'fred' fred, соединение от узла с IP-адресом 144.155.166.177
'144.155.166.%' 'fred' fred, соединение от любого узла в144.155.166 class C подсеть
'144.155.166.0/255.255.255.0' 'fred' То же самое как предыдущий пример

Для имени хоста клиента и имени пользователя входящего соединения возможно соответствовать больше чем одну строку в user таблица. Предыдущий набор примеров демонстрирует это: Несколько из записей, показанных соответствие соединение от thomas.loc.gov fred.

Когда многократные соответствия возможны, сервер должен определить который из них, чтобы использовать. Это решает этот вопрос следующим образом:

Использование сервера, сортирующее правила, что строки порядка с самым специфичным Host значения сначала. Литеральные имена хоста и IP-адреса являются самыми определенными. (На специфику литерального IP-адреса не влияют тем, есть ли у нее сетевая маска, таким образом, 192.168.1.13 и 192.168.1.0/255.255.255.0 считаются одинаково определенными.) Образец '%' означает "любой узел" и является наименее определенным. Пустая строка '' также означает "любой узел", но виды после '%'. Строки с тем же самым Host значение упорядочивается с самым специфичным User значения сначала (пробел User значение означает "любого пользователя" и является наименее определенным).

Чтобы видеть, как это работает, предположите что user таблица похожа на это:

+-----------+----------+-| Host      | User     | ...+-----------+----------+-| %         | root     | ...| %         | jeffrey  | ...| localhost | root     | ...| localhost |          | ...+-----------+----------+-

Когда сервер читает таблицу в память, это сортирует строки, используя правила, только описанные. Результат после сортировки похож на это:

+-----------+----------+-| Host      | User     | ...+-----------+----------+-| localhost | root     | ...| localhost |          | ...| %         | jeffrey  | ...| %         | root     | ...+-----------+----------+-

Когда клиент пытается соединиться, сервер просматривает сортированные строки и использует первое найденное соответствие. Для соединения от localhost jeffrey, две из строк от табличного соответствия: тот с Host и User значения 'localhost' и '', и тот со значениями '%' и 'jeffrey'. 'localhost' строка кажется первой в сортированном порядке, так, чтобы был тот использование сервера.

Вот другой пример. Предположите что user таблица похожа на это:

+----------------+----------+-| Host           | User     | ...+----------------+----------+-| %              | jeffrey  | ...| thomas.loc.gov |          | ...+----------------+----------+-

Сортированная таблица похожа на это:

+----------------+----------+-| Host           | User     | ...+----------------+----------+-| thomas.loc.gov |          | ...| %              | jeffrey  | ...+----------------+----------+-

Соединение jeffrey от thomas.loc.gov является соответствующим первой строкой, тогда как соединение jeffrey от любого узла является соответствующим вторым.

Отметить

Это - распространенное заблуждение, чтобы думать, что для данного имени пользователя все строки, которые явно называют того пользователя, используются сначала, когда сервер пытается счесть достойным соединения. Это не истина. Предыдущий пример иллюстрирует это, где соединение от thomas.loc.gov jeffrey является сначала соответствующим не строкой, содержащей 'jeffrey' как User значение столбца, но строкой без имени пользователя. В результате jeffrey аутентифицируется как анонимный пользователь, даже при том, что он определил имя пользователя, соединяясь.

Если Вы в состоянии соединиться с сервером, но Ваши полномочия не состоят в том тем, что Вы ожидаете, Вы, вероятно, аутентифицируетесь как некоторая другая учетная запись. Чтобы узнать, что считает сервер используемым, чтобы аутентифицировать Вас, используйте CURRENT_USER() функция. (См. Раздел 12.14, "информационные Функции".) Это возвращает значение в user_name@host_name формат, который указывает User и Host значения от соответствия user строка таблицы. Предположите это jeffrey соединяет и выпускает следующий запрос:

mysql> SELECT CURRENT_USER();+----------------+| CURRENT_USER() |+----------------+| @localhost     |+----------------+

Результат, показанный здесь, указывает что соответствие user у строки таблицы был пробел User значение столбца. Другими словами сервер обрабатывает jeffrey как анонимный пользователь.

Другой способ диагностировать проблемы аутентификации состоит в том, чтобы распечатать user таблица и вид это вручную, чтобы видеть, где первое соответствие делается.