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

14

Если я войду в систему с паролем root, я могу просто напечатать

mysqldump --all-database и я получу ожидаемый "дамп".

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

mysqldump: получена ошибка: 1045: доступ запрещен для пользователя 'root' @ 'localhost' (с использованием пароля: НЕТ)

при попытке подключения. Я не хочу жестко кодировать пароль root базы данных mysql в скрипте (кто бы).

Учитывая, что я могу просто набрать «mysqldump» в командной строке в моей оболочке bash, нужно каким-то образом обойти использование параметра -u. У меня уже есть #! / Bin / bash в верхней части скрипта.

Чего мне не хватает здесь, чтобы заставить это не запрашивать пароль root для базы данных?

mysql scripting cron

— Mech Software
источник

12

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

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

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

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

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

— Zoredache
источник

1

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

— Mech Software

> либо у вас не установлен пароль root, либо у вас есть файл конфигурации, который не найден вашим скриптом. Автор четко заявляет, что для root существует пароль mysql, и он пытается получить доступ к базе данных, не передавая ее команде mysqldump: «(используя пароль: НЕТ)». Следовательно, доступ запрещен, ошибка.

— мономиф

1

@monomyth, автор также заявляет, что он может войти в систему без пароля, в то время как он в интерактивном режиме вошел как root. Это говорит мне, что что-то не так.

— Зоредаче

2

@Mech Software, нет смысла пытаться защитить себя от учетной записи root. Если у кого-то есть учетная запись root, он может просто перезапустить mysql и полностью обойти систему разрешений.

— Зоредаче

1

Причиной того, что я смог войти в систему, было то, что для учетной записи root был указан файл .my.cnf с 600 разрешениями, так что именно так оболочка получала доступ. Однако cron должен игнорировать файл, поэтому я использовал параметр в этом посте, чтобы указать на него.

— Mech Software

3

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

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

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

— мономиф
источник

1

Я думаю, что я до сих пор не понимаю, что если я могу набрать (из командной строки root) mysqldump без ввода пароля, почему я не могу запустить его через задание cron таким же образом. Какая часть отсутствует, для которой требуется параметр -p. Я не пытаюсь «скрыть» пароль, я просто никогда не буду его вводить. Что-то особенное для самого имени пользователя root разрешает доступ, так почему же это нельзя воспроизвести с помощью cron?

— Mech Software

Если вы видите, что вы можете войти без пароля и с паролем, используя одного и того же пользователя «root», возможно, в вашей базе данных mysql есть несколько пользователей root. Некоторые из них могут не иметь установленного пароля. Вы можете удалить пароль из «root» @ «localhost», но тогда не только cron сможет подключиться к вашей базе данных, но и любой пользователь с локальной учетной записью. Это ничем не отличается (или хуже), чем иметь пароль в сценарии с открытым текстом.

— мономиф

Я думаю, суть в том, что MechSoftware создавал то, что будучи пользователем root, вы по существу предоставляете доступ для чтения к файлам базы данных, а они не шифруются. Следовательно, требование пароля root MySQL от пользователя root только для печати данных, к которым он, по сути, уже имеет доступ, является «безопасностью через неизвестность». Кроме того, разрешения очень легко испортить, например, если кто-то устанавливает их рекурсивно для каталога, если есть символическая ссылка на файл и т. Д.

— Septagram

2

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

Крон не имеет такой роскоши. Когда он входит (как 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

— gbjbaanb
источник

1

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

[client]
user = DBUSERNAME
password = DBPASSWORD

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

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

— Мартейн Хеемельс
источник

1

Я обнаружил, что это был случай, КАК я смог использовать mysqldump без пароля. Так что это решило тайну того, как это делает SHELL, так почему cron не читает это?

— Mech Software

1

mysqldump при запуске из cron может не найти файл .my.cnf. Для этого нужно добавить параметр mysqldump для явного чтения параметров в файле .my.cnf, т.е. --defaults-extra-file = / root / .my.cnf. Я узнал об этом из двух других ответов о переполнении стека. См stackoverflow.com/a/602054/854680 и stackoverflow.com/a/890554/854680

— MikeOnline

1

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

Советы для cron:

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

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

0

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

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

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

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

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

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

— Барри Шеин
источник

1

Ввод учетных данных /root/.my.cnfс надлежащими разрешениями аккуратно решает проблему.

— Майкл Хэмптон

Я не согласен, теперь любой, кто может получить доступ к этому файлу, в том числе через какой-либо другой системный недостаток, имеет root-файл mysql pw. И он должен быть атакован 24x7, и в фиксированном месте файла (правда, он не должен быть в / root.) Но, например, тот, кто запускает дампы файловой системы или может получить доступ к нему, может вытащить его из файл дампа файловой системы. В таком случае это звучит как соблазн недовольного сотрудника. Я думаю, что разумной целью является отсутствие паролей в открытом виде в системе, где бы то ни было.

— Барри Шейн

Может быть и так, но сделанное вами предложение гораздо хуже, поскольку оно позволяет любому локальному пользователю тривиально притворяться пользователем root.

— Майкл Хэмптон

Нет, мое предложение заключалось в том, что они уже должны быть пользователями root на локальном сервере, и в этом случае локальный mysqld доверяет mysql или mysqldump и т. Д. (Клиент), запущенный от имени пользователя root, и позволяет им действовать так, как если бы они были аутентифицированы как root mysql. , Как я уже сказал, если они уже root-юникс unix для сервера, они могут в любом случае обойти пароль root mysql с помощью нескольких хорошо задокументированных команд («восстановление пароля root mysql»).

— Барри Шеин