Нужна копия каталога только для чтения: проверяем readonly bind

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

Отделить представление от данных

Bind показывает существующее дерево в другой точке. Данные остаются общими. Если производитель обновит файл через исходный путь, читатель увидит изменение. Поэтому такой приём подходит для ограничения записи через конкретное представление, но не заменяет согласованный snapshot для воспроизводимого анализа.

mkdir /mnt/results-ro
mount --bind /srv/results /mnt/results-ro
mount -o remount,bind,ro /mnt/results-ro
findmnt -T /mnt/results-ro -o TARGET,SOURCE,VFS-OPTIONS,FS-OPTIONS

Это пример административных действий на отдельном стенде с новым пустым каталогом назначения. Двухшаговая форма явно создаёт bind и затем меняет флаг его представления. На некоторых версиях util-linux есть дополнительные способы выразить это за один вызов; выбирайте синтаксис, поддерживаемый целевой системой.

Проверить обе стороны

Посмотрите VFS-OPTIONS у /mnt/results-ro и исходного /srv/results. Readonly может относиться к конкретному mount, в то время как сама файловая система остаётся writable через другое представление. Это и позволяет производителю продолжать работу. Различие VFS и filesystem flags разобрано в mount(8).

На учебном файле проверьте: запись через /mnt/results-ro получает Read-only file system, а согласованная запись через /srv/results проходит и становится видна с readonly-стороны. Если тест выполняется от обычного пользователя, убедитесь, что отказ не вызван исходными DAC-правами: иначе он не подтверждает readonly.

Проверить вложенные монтирования

Обычный --bind не переносит всё дерево вложенных mounts так, как --rbind. При наличии вложенных томов сначала инвентаризируйте их. Рекурсивная readonly-политика имеет дополнительные особенности и зависит от поддерживаемого синтаксиса и ядра. Нельзя считать одно remount корня доказательством readonly у каждого вложенного mount.

Если процессу доступен исходный writable-путь или он имеет права менять mounts, это представление само по себе не ограждает данные. Ограничение путей и привилегий процесса — отдельная часть настройки. Для systemd-службы может быть удобнее описать доступ средствами unit, чем создавать глобальный mount для всей машины.

Проверить способ публикации файлов

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

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

Откройте программу Linux и Bash для DevOps-инженеров. Практика с файловой системой и сервисами поможет выбирать доступ под задачу приложения и проверять его на реальных операциях чтения и записи.

Ещё по теме

• После mount файлы исчезли: как найти скрытые данные каталога
• Mount появился в другом окружении: проверяем propagation