Права и безопасность

Резервная копия боевого сайта — файл, из которого извлекается всё: пароль базы данных из 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.

Как выдать доступ группе

Способ первый, точечный — назначить группе готовую политику:

1. Безопасность → Права доступа → Группы пользователей, нужная группа.
2. Вкладка Доступ к контекстам: контекст mgr, минимальный ранг, политика mxbackupDefault.
3. Сохранить и очистить кэш.

Способ второй, если у сайта уже своя политика доступа к менеджеру: откройте её и добавьте нужные права (mxbackup_view, mxbackup_manage, mxbackup_run, mxbackup_restore) в список разрешённых. Это удобнее, когда права менеджера собраны в одном месте, и позволяет выдать не всё сразу.

CLI прав MODX не проверяет: тот, у кого есть доступ к консоли сервера от имени пользователя сайта, и так может сделать с сайтом что угодно.

Каталог архивов

Путь проверяется до начала работы, и небезопасный отклоняется.

Запрещено	Почему
Внутри webroot	Архив можно скачать по прямой ссылке
Корень сайта	То же самое, плюс архив попадёт в следующую копию
core/cache и вложенные каталоги	Каталог чистится MODX; копия исчезнет молча
Относительный путь	Результат зависит от того, откуда запущен процесс

Запрет на webroot снимается ключом allow_web_storage в общем файле настроек, но делать это без крайней необходимости не нужно — см. Системные настройки. Запреты на корень сайта и core/cache действуют всегда.

Рекомендации по правам файловой системы:

• каталог архивов — вне webroot, владелец — пользователь сайта, режим 0700;
• копии, которые забирает внешний скрипт, лучше складывать в отдельный каталог, а не отдавать доступ ко всему хранилищу;
• задания cron запускайте от пользователя сайта: архив, созданный под root, не удалится при ротации.

Секреты внутри архива

Production-копия содержит файлы сайта целиком, включая конфигурацию с паролями и ключами. Отсюда несколько правил.

• Почта выключена по умолчанию. Включив её, вы отправляете отчёт (а при небольшом размере — и сам архив) по каналу, который вы не контролируете. Ограничение размера вложения задаётся настройкой mxbackup.mail_max_attachment_mb.
• Для передачи копии наружу используйте dev-профиль — база в нём уже обезличена. Из состава файлов dev по умолчанию исключён каталог core/config/.
• Для передачи по недоверенному каналу включайте AES-256. Шифруется содержимое файлов; имена файлов внутри архива остаются видимыми. См. Профили.
• Пароль архива хранится открытым в PHP-файле профиля с правами 0640. Это осознанное решение: пароль защищает архив в пути, а не при компрометации сервера. Каталог профилей должен быть недоступен по HTTP.

Блокировка параллельных запусков

Перед началом работы пакет захватывает файл .mxbackup.lock в каталоге архивов. Второй запуск в это время завершается ошибкой Другой backup уже выполняется — это защита от двух процессов, одновременно пишущих в один каталог.

Файл блокировки намеренно не удаляется после завершения: удаление освобождённого файла создаёт состояние гонки, при котором два процесса могут получить блокировку одновременно. Наличие файла ничего не значит, значение имеет только удерживаемая блокировка; внутри записаны pid и время старта — по ним разбирают зависший запуск.

Настройка mxbackup.lock_ttl_minutes — справочная: она пишется в файл для диагностики и сама блокировку не снимает.

Что пишется в журнал

Запуск, завершение и ошибки уходят в mxLogger с тэгами mxbackup и backup, а при его отсутствии — в стандартный журнал MODX с префиксом [mxbackup]. Восстановление логируется уровнем warning, чтобы его было видно в общей ленте.

Пароль архива в журнал, отчёт, манифест и историю не попадает ни при каких обстоятельствах.

Чего пакет не делает

• Не закрывает сайт на время восстановления. Настройку «Сайт опубликован» переключаете вы сами — см. Восстановление.
• Не отправляет архивы в S3, FTP или WebDAV. Забирать копии из каталога хранения нужно внешними средствами.
• Не проверяет подлинность архива. Контрольная сумма ловит порчу файла, но подписи нет — восстанавливайте только архивы из доверенного источника.
• Не хранит копии за пределами сервера. Резервная копия, лежащая на том же диске, что и сайт, не спасает от отказа диска: настройте вывоз архивов на отдельное хранилище.