Как стать автором
Обновить

~/mysql_history и безопасность

Время на прочтение1 мин
Количество просмотров3.3K
Как правило, безопасность обратно пропорциональна удобству. Сохранять историю команд, по которой можно перемещаться в CLI, — очень удобно. Так делает, например, bash. Так делает и MySQL, бережно и построчно записывая команды в ~/.mysql_history в виде простого текста (включая пароли).

Снизить риск или полностью избежать утечки можно, если (от более допустимых, на мой взгляд, способов к менее допустимым):
  • домашняя директория пользователя имеет режим доступа 700;
  • файл ~/.mysql_history имеет режим доступа 600;
  • вызывать сценарий, который чистит файл ~/.mysql_history от «лишних» записей;
  • «вручную» чистить файл ~/.mysql_history от «лишних» записей;
  • удалить файл ~/.mysql_history (этот вариант предлагает SecurityFocus);
  • ~/.mysql_history является символической ссылкой на /dev/null (история не ведется).

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

Собственно зачем затронута эта тема. Какие есть еще варианты?

Bonus track. Затрагивая вопрос о безопасности MySQL, хочу отметить, что часто наблюдаю данные учетной записи root в сценариях резервного копирования, использующих mysqldump. Очень распространенная ошибка, а ведь не так уж и сложно создать специального пользователя для выгрузки баз парой команд:
GRANT SELECT, LOCK TABLES ON .* TO <user-dumper>@localhost IDENTIFIED BY '<dumper-password>';
FLUSH PRIVILEGES;
Теги:
Хабы:
Всего голосов 8: ↑6 и ↓2+4
Комментарии2

Публикации

Истории

Работа

Ближайшие события

Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн
Антиконференция X5 Future Night
Дата30 мая
Время11:00 – 23:00
Место
Онлайн
Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург