4.2.9 Управление доступом, этап 1: верификация подсоединения

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

Личность задается двумя порциями информации:

• хостом, с которого вы подсоединяетесь
• вашим именем пользователя MySQL

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

Значения в полях контекста таблицы user могут задаваться следующим образом:

• В поле Host может указываться имя хоста, либо его IP-адрес, либо 'localhost' для обозначения локального хоста.
• В поле Host разрешается использовать шаблонные символы `%' и `_'.
• Значение '%' в поле Host означает любое имя хоста.
• Пустое значение в поле Host означает, что к этой привилегии должна быть добавлена запись в таблице host, совпадающая с заданным именем хоста. Дополнительную информацию по данной теме вы найдете в следующем разделе.
• Начиная с версии MySQL 3.23 для значений в поле в поле Host, определенных в виде IP-адресов, можно задавать сетевую маску, указывающую, сколько разрядов адреса будет использоваться для указания номера сети. Например:

  mysql> GRANT ALL PRIVILEGES ON db.*
      -> TO david'192.58.197.0/255.255.255.0';
  

  В этом случае все IP-адреса, для которых выполняется следующее условие:

  user_ip & netmask = host_ip.
  

  являются разрешенными для подсоединения. В предыдущем примере все IP-адреса в диапазоне от 192.58.197.0 до 192.58.197.255 являются разрешенными для подсоединения к серверу MySQL.
• В поле User запрещено использовать шаблонные символы, но пустое значение разрешено, и оно соответствует любому имени. Если запись в таблице user, соответствующая входящему подсоединению, содержит пустое имя пользователя, данный пользователь считается анонимным пользователем (пользователем без имени), а заданное клиентом имя пользователя игнорируется. Это означает, что при всех последующих проверках доступа, осуществляемых на протяжении данного соединения (т.е. на этапе 2), будет использоваться пустое имя пользователя.
• Поле Password может быть пустым. Это не означает, что в данном случае подходит любой пароль. Если поле пароля пусто, пользователь должен быть подсоединен без указания какого либо пароля.

Непустые значения в поле Password представляют собой зашифрованные пароли. В MySQL пароли не хранятся в виде открытого текста, который может прочитать кто угодно. Напротив, пароль, который вводится пользователем при попытке подсоединения, шифруется (с помощью функции PASSWORD()). В дальнейшем зашифрованный пароль используется клиентом/сервером в процессе проверки его правильности (это делается вообще без пересылки пароля во время подсоединения). Заметим, что с MySQL считает зашифрованный пароль РЕАЛЬНЫМ паролем, поэтому не следует допускать к нему кого бы то ни было! В частности, не разрешайте обычным пользователям доступ для чтения к таблицам в базе mysql!

Примеры, приведенные ниже, показывают, каким входящим подсоединениям соответствуют различные комбинации значений, указанных в полях Host и User таблицы user:

Поскольку в IP-адресе, указываемом в поле Host, могут использоваться шаблонные символы (например '144.155.166.%' - данное значение соответствует всем без исключения хостам указанной подсети), возникает опасность, что кто-нибудь может попытаться воспользоваться этой возможностью, указав имя хоста, например, как 144.155.166.somewhere.com. Чтобы ``поставить заслон'' таким попыткам, в MySQL не разрешены имена хостов, начинающиеся с цифр и точки. Другими словами, имени хоста типа 1.2.foo.com, никогда не найдется соответствия в столбцах Host таблиц привилегий. IP-адресу с шаблонными символами может соответствовать только IP-адрес.

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

Сортировка таблицы user осуществляется следующим образом. Предположим, таблица user имеет следующий вид:

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

При считывании этой таблицы сервер упорядочивает записи, начиная с наиболее конкретных значений в столбце Host ('%' в столбце Host означает ``любой хост'' и является наименее конкретным). Записи с одинаковым значением в столбце Host упорядочиваются между собой начиная с наиболее конкретных значений в столбце User (пустое значение в столбце User означает ``любой пользователь'' и является наименее конкретным). Окончательно отсортированная таблица user имеет следующий вид:

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

При попытке подсоединения сервер просматривает отсортированные записи и использует первую подходящую запись. Для подсоединения с localhost пользователя jeffrey первыми подходящими записями являются записи со значением 'localhost' в столбце Host. Из них запись с пустым значением имени пользователя соответствует и имени подсоединяющегося хоста и имени пользователя. (запись '%'/'jeffrey' тоже подошла бы, но она -- не первая подходящая в этой таблице).

Рассмотрим другой пример. Пусть таблица user имеет вид:

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

Отсортированная таблица выглядит следующим образом:

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

Для подсоединения пользователя jeffrey с thomas.loc.gov подходит первая запись, в то время как для подсоединения jeffrey с whitehouse.gov - вторая.

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

Если у вас возникают проблемы с подсоединением к серверу, распечатайте таблицу user и отсортируйте ее вручную, чтобы увидеть, где происходит первое совпадение.

User Comments

I installed the binary distribution on a new
server running solaris 2.7 (although this could
happen on anything). When I went to set the
initial password for root and root@myhost per the
INSTALL documentation it accepted the root
password but then said it would not allow
connections from the fully qualified domain name
(myhost.myhome.com) of the server it resided on...
Of course I looked at the Host and User columns in
the mysql:user table and didn't get anywhere....
finally I realized it was using the FQDN from the
/etc/hosts file (which when properly formatted
includes IP,FQDN,NAME,ALIAS,ALIAS,ALIAS). Updated
/etc/nsswitch.conf to use dns and voila, it works
fine now). Easy to overlook.

After viewing the previous comment, I solved a
similar problem. Apparently mySQL doesn't like hard
addressses. I coun't login to mySQL from a remote
client no matter what permissions I gave the user.
Once I added an entry like the following:

<blockquote>
192.214.33.156 myRemoteHost
</blockquote>
to the /etc/hosts file, problem was solved.

Under 3.23.55 with syntax as follows:
GRANT ... ON `foo\_bar`.* TO ...

results in:
Unknown command '\_'

However it appears the grant tables are still updated.
Strange

Add your own comment.