7.16. Файлы журналов

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

Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

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

SHOW LOGS выводит информацию о существующих журналах.

7.17. Как обезопасить MySql от хакеров

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

1. У всех пользователей MySQL должны быть пароли. Для приложений клиент/сервер является общепринятым, что клиент может указывать любое имя пользователя, но если для other_user не задан пароль, то кто угодно может зайти под любым именем, просто введя mysql -u other_user db_name. Чтобы этого избежать, можно изменить пароль для всех пользователей, отредактировав скрипт mysql_install_db перед запуском приложения, или только пароль для root-пользователя MySQL, как это показано ниже:

shell> mysql -u root mysql

mysql> UPDATE user SET Password=PASSWORD('new_password')

WHERE user='root';

mysql> FLUSH PRIVILEGES;

2. Не предоставляйте привилегии PROCESS всем пользователям. Команда mysqladmin PROCESSLIST выводит текст запросов, обрабатываемых в данный момент. Следовательно, любой пользователь, имеющий право на выполнение этой команды, получает возможность прочитать, например, такой запрос другого пользователя, как UPDATE user SET password=PASSWORD('not_secure'). mysqld резервирует добавочное подключение для пользователей, имеющих привилегию PROCESS, так что пользователь MySQL под именем root может подключиться и осуществлять контроль даже в том случае, когда все обычные подключения заняты.

3. Не предоставляйте привилегии FILE всем пользователям. Любой пользователь, имеющий такую привилегию, может записать в любом месте файловой системы файл с привилегиями демона mysqld! Чтобы обеспечить здесь хоть минимальную защиту, все файлы создаваемые с помощью команды SELECT ... INTO OUTFILE, сделаны общедоступными для записи, но перезаписать существующие файлы нельзя.

Привилегия FILE может быть также использована для чтения любого файла, доступного пользователю Unix, от имени которого запускается сервер.

Можно также прочитать любой файл в текущую базу данных. Это может быть использовано в корыстных целях. Возможно, например, с помощью команды LOAD DATA загрузить /etc/passwd в таблицу и прочитать ее позже с помощью SELECT.

4. Чтобы ограничить число подключений, доступных для отдельного пользователя, можно в mysqld задать значение переменной max_user_connections.