Blogerator.org

× Версия для печати

Продолжаем начатый ранее разговор.

Безопасность в MySQL всегда была делом тонким: во-первых, из-за того, что применение некоторых штатных команд изобилует рядом неочевидных побочных моментов, во-вторых, здесь доступны более скромные возможности администрирования пользователей (по сравнению с другими ведущими мировыми СУБД). Давайте поясним эти два характерных аспекта на практических примерах, а затем попытаемся отчасти компенсировать указанные слабые места MySQL силами специализированных сторонних решений.

Такой загадочный GRANT

Для иллюстрирования сказанного выберем важную тему — присвоение и делегирования прав с помощью GRANT . Эта команда позволяет назначать как отдельные привилегии, так и выдавать весь спектр возможностей для администраторов БД (в таком случае можно воспользоваться мета-подстановкой ALL PRIVILEGES ).

После очень краткой теории, давайте посмотрим, как это работает:

root@mysql-5.5.17> GRANT ALL PRIVILEGES ON consumer.* TO 'super_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'super_usr'@'localhost';
+-----------------------------------------------------------------+
| Grants for super_usr@localhost                                  |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO super_usr'@'localhost'                    |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'super_usr'@'localhost' |
+-----------------------------------------------------------------+

Как видим, мы получили аккаунт с полными привилегиями.

Продолжим демонстрацию ещё одним примером присвоения прав, который вскрывает коварность этой команды:

root@mysql-5.5.17> GRANT EXECUTE, INSERT, SELECT, UPDATE ON `consumer`.* TO 'usual_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'usual_usr'@'localhost';
+----------------------------------------------------------------+
| Grants for usual_usr@localhost                                 |
+----------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'usual_usr'@'localhost'                  |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'usual_usr'@'localhost'|
+----------------------------------------------------------------+

Здесь мы присваиваем четко ограниченный набор привилегий другому пользователю этого же домена, но в итоге видим, что он получил сразу весь набор привилегий.

Удивлены? Если кто-то в Oracle считает это логичным, когда мы явно присваиваем одно, а неявно получаем совсем другое — я так не считаю. Перейдем к следующему примеру, связанному с перетеканием привилегий уже через оператор «WITH GRANT OPTION »:

root@mysql-5.5.17> GRANT INSERT, UPDATE ON consumer.City TO 'alaura'@'localhost';
root@mysql-5.5.17> GRANT SELECT ON consumer.City TO 
'alaura'@'localhost' WITH GRANT OPTION;
root@mysql-5.5.17> SHOW GRANTS FOR 'alaura'@'localhost';
+---------------------------------------------------------+
| Grants for alaura@localhost                             |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO 'alaura'@'localhost'              |
| GRANT SELECT,INSERT,UPDATE ON `consumer`.`City`         |
| TO 'alaura'@'localhost' WITH GRANT OPTION               |
+---------------------------------------------------------+

Синтаксис второй команды недвусмысленно говорит, что мы передаем «WITH GRANT OPTION » для привилегии SELECT , но вывод результата утверждает обратное. Думаю, администраторы MySQL вряд ли будут хоть сколько-то удивлены подобной логикой, но как я неоднократно имел возможность наблюдать, операторы других известных СУБД были явно озадачены подобным развитием событий.

В этом плане синтаксис MySQL вводит в заблуждение, хотя бы тем, что позволяет без ошибки исполнять подобные действия

Я привел лишь один вариант неоднозначности, хотя в MySQL таковых имеется множество. И если администратор в этой ситуации может просто быть внимательным, то многие веб-приложения для управления этой СУБД, (например популярный phpMyAdmin), не всегда учитывают такие мелочи.

Но цель сегодняшнего обзора не в обсуждении подобных «слабых мест» и нелогичностей в MySQL — наш подход более конструктивен:

далее мы обсудим инструменты, позволяющие оперативно отслеживать и активно выявлять подобные аномалии (и их последствия), которые неизбежны в любой большой и сложной MySQL-системе

~

Читать этот материал дальше. Оглавление и начало этой серии статей — здесь.

Игорь Савчук ©  Системный Администратор, 2012