Безопасность

Головоломка с привилегиями (продолжение)

В лекции ""Ведение файлов журналов"" была рассмотрена ситуация, когда присвоенные администратором привилегии не позволяли достигать желаемого уровня доступа. Если помните, проблема возникала с новой инсталляцией MySQL, администратор которой добавлял запись для пользователя, тем самым разрешая ему подключаться к серверу с нескольких компьютеров. Очевидный способ определить подобный доступ — воспользоваться спецификатором имени компьютера с символом "%". Следовательно, администратор создает учетную запись пользователя с помощью следующего оператора:

GRANT ALL ON samp db.* TO fred@%.snake .net IDENTIFIED BY "cocoa"

Если пользователь fred имеет учетную запись на компьютере с сервером, то он попытается подключиться с него и получит следующий ответ:

% mysql -u fred -pcocoa samp_db 
ERROR 1045: Access denied for user: 'fred@localhost' 
(Using password: YES)

Почему же так происходит? Чтобы понять это, необходимо разобраться, как сценарий mysql install db создает исходные таблицы разрешений и как сервер проверяет соответствие данных клиентских соединений и записей таблицы user. При инициализации баз данных в процессе работы mysql install db создает записи в таблице user со следующим значениями таблиц Host и User.

+---------------------+------+
| Host                | User |
+---------------------+------+
| Localhost           | root |
| pit-viper.snake.net | root |
| localhost           |      |
| pit-viper.snake.net |      |
+---------------------+------+

Первые две записи позволяют пользователю root подключиться к локальному компьютеру, определив либо localhost, либо собственно имя компьютера. Вторые две записи разрешают анонимное соединение с локальным компьютером. При добавлении записи для пользователя fred таблица принимает следующий вид:

+---------------------+------+
| Host                | User |
+---------------------+------+
| Localhost           | root |
| pit-viper.snake.net | root |
| localhost           |      |
| pit-viper.snake.net |      |
| %.snake.net         | fred |
+---------------------+------+

В процессе запуска сервер считывает эти записи и сортирует их (сначала по имени компьютера, а затем по пользователям). В результате более определенные значения оказываются первыми, а менее определенные — последними.

+---------------------+------+
| Host                | User |
+---------------------+------+
| Localhost           | root |
| localhost           |      |
| pit-viper.snake.net | root |
| pit-viper.snake.net |      |
| %.snake.net         | fred |
+---------------------+------+

Две записи для компьютера localhost располагаются рядом. Запись для пользователя root размещается первой, поскольку она является более полной. Аналогичным образом и в таком же порядке размещаются и записи компьютера pit-viper.snake.net. Все эти записи имеют в столбце Host буквенные значения безо всяких специальных символов, поэтому и располагаются перед записью для пользователя fred, включающей один специальный символ. Соответственно, записи анонимных пользователей имеют приоритет перед записью пользователя fred.

Когда пользователь fred предпринимает попытку подключиться к серверу с локального компьютера, его данным соответствует запись с пустым именем пользователя, которая в порядке сортировки располагается перед записью с %.snake.net. Поскольку анонимные пользователи не применяют пароли, то и эта запись включает пустое значение пароля. Поскольку fred вводит пароль при подключении, возникает несоответствие, и соединение не устанавливается.

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

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

mysql> DELETE FROM user WHERE User = ";

Чтобы быть полностью уверенным, что такая коллизия не произойдет в будущем, удалите записи анонимных пользователей и из всех других таблиц разрешений. Подобные записи имеются в таблицах db, tables_priv и columns_priv

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