Таблица 12.3. Учет регистра в столбцах области таблиц разрешений

Проверка запроса

Каждый раз при получении запроса сервер проверяет в таблицах разрешений, обладает ли отправивший запрос пользователь достаточными полномочиями для его исполнения. Для этих целей таблицы user, db, tables priv и column priv просматриваются в установленном порядке до тех пор, пока не будет определено, что доступ разрешен, либо не будут проверены все таблицы разрешений. Более подробно этот процесс выглядит следующим образом.

1. При первоначальном подключении сервер проверяет записи таблицы user, пытаясь определить глобальные привилегии подключающегося пользователя. Если таковые имеются и, более того, являются достаточными для выполнения запроса, сервер обрабатывает запрос,

2. Если имеющихся глобальных привилегий недостаточно, сервер ищет дополнительные привилегии в таблице db. Если найденные привилегии позволяют выполнить запрос, сервер его обрабатывает.

Как хранятся пароли в таблице user

Пароли представлены в этой таблице в виде зашифрованных строк, поэтому узнать их не может даже пользователь, имеющий права доступа к этой таблице. Довольно широко распространено мнение, что функция PASSWORD о применяет методы кодирования, используемые и для шифрования паролей UNIX, однако оно ошибочно.

Эти два способа кодирования действительно подобны в том отношении, что являются односторонними, т.е. необратимыми. Однако сервер MySQL использует иной алгоритм шифрования, чем UNIX. Это означает, что даже если UNIX-пароль является одновременно и паролем MySQL, зашифрованные строки пароля совпадать не будут. Чтобы использовать для приложения средства шифрования UNIX, вместо PASSWORD () запустите функцию

CRYPT О .

3. Если набора глобальных привилегий и привилегий баз данных недостаточно, сервер продолжает поиск сначала в таблице tablespriv, а потом и в coluims priv.

4. Если после проверки всех таблиц разрешений достаточных полномочий не найдено, сервер отклоняет попытку выполнения запроса.

Говоря на языке булевой алгебры, привилегии таблиц разрешений используются сервером следующим образом:

user OR db OR tables priv OR columns priv

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

user OR (db AND host) OR tables priv OR columns priv

Упрощенный вариант был представлен исключительно для того, чтобы показать, что таблица host не подвержена влиянию операторов GRANT и REVOKE. Администраторы, управляющие привилегиями пользователей с помощью операторов GRANT и REVOKE, могут забыть о таблице host по следующим причинам.

Проверяя привилегии уровня базы данных, сервер ищет запись для клиента в таблице db. Пустое значение столбца Host означает примерно следующее: проверьте таблицу host, чтобы определить, какие компьютеры могут получать доступ к базе данных.

Сервер ищет в таблице host записи с таким же значением столбца Db, как и в записи таблицы db. Если компьютер подключающегося клиента не указан ни в одной записи таблицы host, следовательно, привилегии для работы с таблицами этому пользователю не предоставлены. Если значение столбца Host хотя бы одной записи этой таблицы соответствует компьютеру подключающегося пользователя, записи таблиц db и host объединяются, что приводит к определению реальных привилегий уровня баз данных клиента.

Привилегии объединяются посредством логического оператора AND. Это означает, что пользователь будет иметь привилегии только в том случае, когда записи о нем будут представлены в обеих таблицах. Таким образом, пользователю может присваиваться базовый набор привилегий в записи таблицы db. Согласно записям таблицы host, получить их можно будет только с определенных компьютеров. Так, например, можно предоставить доступ к базам данных со всех компьютеров домена, но убрать эти привилегии для пользователей компьютеров, расположенных в менее защищенной области.

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

Например, если новый пользователь создается администратором путем добавления новой записи в таблицу user с помощью оператора INSERT, он не сможет сразу же подключиться к серверу. Начинающих администраторов (а иногда и достаточно опытных) это зачастую весьма сильно раздражает, хотя решение этой проблемы предельно просто: достаточно указать серверу перезафузить таблицы разрешений сразу после внесения изменений. Это можно осуществить с помощью оператора FLUSH PRIVILEGES ИЛИ КОМанды mysqladmin flush-privileges (либо mysqladmin reload, если используется более старая версия, не поддерживающая flush-privileges).

Порядок сравнения столбцов

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

Считывая содержимое таблицы user, сервер сортирует ее записи, согласно значениям столбцов Host и User. Доминирующую роль здесь играет значение столбца Host (т.е. записи с одинаковыми значениями столбца Host размешаются рядом, а затем упорядочиваются по значению User). Однако выполняемая сортировка не является лексикофафической, или, скорее, является таковой лишь частично. Основной принцип - более высокий приоритет символьных значений по сравнению со специальными символами. Это означает, что если пользователь подключается к компьютеру boa.snake.net, а в таблице имеются записи со значениями boa.snake.net и %.snake.net, будет выбрана именно первая запись. Аналогичным образом, значение %.snake.net имеет больший приоритет, чем %.net, которое, в свою очередь, более приоритетно, чем %. Точно также обрабатываются и IP-адреса. Порядок приоритетности значений для пользователя, подключающегося с компьютера с IP-адресом 192.168.3.14, будет выглядеть следующим образом: 192.168.3.14, 192.168.3.%, 192.168.%, 192.% И %.