Резервная копия боевого сайта — файл, из которого извлекается всё: пароль базы данных из core/config/config.inc.php, ключи платёжных систем, хеши паролей пользователей, персональные данные покупателей. Поэтому доступ к mxBackup и к каталогу архивов стоит настраивать так же аккуратно, как доступ к самому серверу.
Пакет создаёт шаблон политик mxbackupTemplate, политику mxbackupDefault и пять прав.
| Право | Что открывает |
|---|---|
load | Загрузку namespace mxBackup |
mxbackup_view | Пункт меню и страницу компонента, списки профилей, правил, таблиц и истории |
mxbackup_manage | Правку профилей, состава таблиц, правил обезличивания и системных настроек пакета |
mxbackup_run | Запуск копии и проверки состава из менеджера |
mxbackup_restore | Предварительную проверку архива и восстановление |
Права проверяются на сервере, в каждом процессоре, а не только в интерфейсе: кнопки скрываются по тем же флагам, но и прямой запрос к коннектору без нужного права ничего не сделает.
Разделение прав рассчитано на типовую ситуацию: контент-менеджеру или разработчику можно дать mxbackup_view и mxbackup_run, чтобы он снимал копии перед своими изменениями, оставив mxbackup_manage и mxbackup_restore за администратором.
Из коробки доступ есть только у sudo
Установщик создаёт политику mxbackupDefault, но не назначает её никому и не трогает существующие политики доступа. Пока администратор не выдаст права, пункт меню и CMP не увидит никто, кроме пользователя с флагом sudo.
Способ первый, точечный — назначить группе готовую политику:
mgr, минимальный ранг, политика mxbackupDefault.Способ второй, если у сайта уже своя политика доступа к менеджеру: откройте её и добавьте нужные права (mxbackup_view, mxbackup_manage, mxbackup_run, mxbackup_restore) в список разрешённых. Это удобнее, когда права менеджера собраны в одном месте, и позволяет выдать не всё сразу.
CLI прав MODX не проверяет: тот, у кого есть доступ к консоли сервера от имени пользователя сайта, и так может сделать с сайтом что угодно.
Путь проверяется до начала работы, и небезопасный отклоняется.
| Запрещено | Почему |
|---|---|
| Внутри webroot | Архив можно скачать по прямой ссылке |
| Корень сайта | То же самое, плюс архив попадёт в следующую копию |
core/cache и вложенные каталоги | Каталог чистится MODX; копия исчезнет молча |
| Относительный путь | Результат зависит от того, откуда запущен процесс |
Запрет на webroot снимается ключом allow_web_storage в общем файле настроек, но делать это без крайней необходимости не нужно — см. Системные настройки. Запреты на корень сайта и core/cache действуют всегда.
Рекомендации по правам файловой системы:
0700;root, не удалится при ротации.Production-копия содержит файлы сайта целиком, включая конфигурацию с паролями и ключами. Отсюда несколько правил.
mxbackup.mail_max_attachment_mb.dev-профиль — база в нём уже обезличена. Из состава файлов dev по умолчанию исключён каталог core/config/.0640. Это осознанное решение: пароль защищает архив в пути, а не при компрометации сервера. Каталог профилей должен быть недоступен по HTTP.Перед началом работы пакет захватывает файл .mxbackup.lock в каталоге архивов. Второй запуск в это время завершается ошибкой Другой backup уже выполняется — это защита от двух процессов, одновременно пишущих в один каталог.
Файл блокировки намеренно не удаляется после завершения: удаление освобождённого файла создаёт состояние гонки, при котором два процесса могут получить блокировку одновременно. Наличие файла ничего не значит, значение имеет только удерживаемая блокировка; внутри записаны pid и время старта — по ним разбирают зависший запуск.
Настройка mxbackup.lock_ttl_minutes — справочная: она пишется в файл для диагностики и сама блокировку не снимает.
Запуск, завершение и ошибки уходят в mxLogger с тэгами mxbackup и backup, а при его отсутствии — в стандартный журнал MODX с префиксом [mxbackup]. Восстановление логируется уровнем warning, чтобы его было видно в общей ленте.
Пароль архива в журнал, отчёт, манифест и историю не попадает ни при каких обстоятельствах.