Использование mysqldump в задании cron без пароля root

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

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

Рекомендуемый вариант - создать файл конфигурации mysql с учетными данными в нем, а затем защитите этот файл разрешениями файловой системы, чтобы только ваш пользователь резервного копирования мог получить к нему доступ.

Возможность входа на сервер mysql при интерактивном входе в систему с правами root, по-видимому, предполагает, что у вас либо не установлен пароль root, либо у вас есть файл конфигурации, который не обнаруживается вашим скриптом. Если у вас есть .my.cnf, вам может потребоваться указать на него вручную. Если для вашей учетной записи root не установлен пароль, я настоятельно рекомендую вам исправить это.

Обновление (2016-06-29) Если вы используете mysql 5.6.6 или выше, вам следует посмотреть на mysql_config_editor инструмент, позволяющий хранить учетные данные в зашифрованном файле. Благодаря Джованни за то, что сказал мне об этом.

Безопасность не должна осуществляться через безвестность. Если вы боитесь, что у кого-то есть доступ к вашей учетной записи root, не имеет значения, хранится ли пароль mysql root в сценарии, поскольку все ваши данные доступны в дампах mysql или файлах базы данных. Итак, настоящий вопрос в том, что вы пытаетесь защитить?

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

Если вы не хотите, чтобы этот пароль mysql был виден любой локальной учетной записью, кроме root, права доступа к файлам в этом сценарии должен быть 0700, а владелец - root.

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

В Cron нет такой роскоши. Когда он входит в систему (как root), он входит в систему с оболочкой по умолчанию. Это не позволяет никому входить в систему удаленно, но также означает, что не запускаются сценарии автоматического входа.

Вы можете настроить оболочку для запуска cron, отредактировать crontab и добавить переменные SHELL и HOME, например.

SHELL=/bin/bash
HOME=/root

если они не установлены, то cron будет работать с оболочкой и домашним каталогом, указанным в / etc / passwd (что, вероятно, ничего, возможно, / bin / sh).

Если вы хотите увидеть, как среда cron запущена, добавьте задание cron, которое экспортирует env в файл, например:

$crontab -e
* * * * * env > /tmp/crontabenv.log
:wq

Если скрипт запускается от root, вы можете создать файл /root/.my.cnf с разрешениями 600 и следующим содержанием:

[client]
user = DBUSERNAME
password = DBPASSWORD

(где вы, конечно же, вводите свое имя пользователя и пароль MySQL).

Этот файл будет автоматически прочитан любым инструментом командной строки mysql, если он запущен от имени пользователя root. Больше не нужно указывать его в командной строкеa. Разрешения 600 защищают его от посторонних глаз.

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

Советы для cron:

• используйте полные пути ко всему - «ECHO = / bin / echo» и т. д .: (определите переменные вверху, чтобы упростить)
• установите MAILTO, чтобы вы получали электронное письмо от каждого задания (или задания перенаправляли stderr / stdout в файл)

Если ваш пользователь root может сделать это из оболочки, cron должен иметь возможность сделать это. Убедитесь, что вы явно указали файл конфигурации для использования в командной строке.

Хотя некоторые из этих ответов полезны, некоторые из них сбивают с толку, потому что пользователь root unix и пользователь root mysql не одно и то же и в основном не имеют никаких отношений, кроме того, что они оба используют имя входа 'root'. Может быть, это очевидно, но кажется, что некоторые ответы объединяют эти два понятия.

Что может быть полезным вариантом (возможно, он существует?) Для mysqld - это разрешить клиентским программам, таким как mysql или mysqldump и т. Д., Работающим от имени пользователя root, получать доступ к корневому каталогу mysqld @ localhost без пароля без необходимости хранить пароль root @ localhost (mysql) в файле my.cnf или аналогичном.

Я знаю, что это заставляет некоторых нервничать, но аргументация заключается в том, что любой, кто работает как локальный (для сервера mysqld) root unix, в любом случае может довольно легко обойти безопасность mysqld. И наличие my.cnf с корневым паролем mysqld 7x24 или даже создание / удаление my.cnf с корневым паролем mysql (откуда этот пароль?) На лету (например, для выполнения mysqldump) делает меня нервничает.

Это потребует некоторой инфраструктуры и размышлений, потому что нужно доверять mysql / mysqldump / etc, чтобы передать mysqld, что он действительно считает, что он запускается локальной учетной записью root unix.

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

P.S. Нет, я не собираюсь прямо здесь проводить мозговой штурм, как что-то из этого может работать в операционной системе, отличной от Unix, хотя эта идея, вероятно, перенесется на другие ОС.