Введение
Конфигурация приложения отчётов уже доступна только для чтения, но само приложение работает как root. Вы обслуживаете его и выбираете подготовленного пользователя, сохраняя реальное создание документов.
В этой независимой среде есть собственный контейнер отчётов и данные. Вы изучите UID и владельца выходного каталога, измените уже знакомое описание запуска, затем пересоздадите и проверите сервис. Сначала завершите «Защита подключённой конфигурации».
Знакомство с пользователем приложения
На этом шаге установите нормальное поведение сервиса и различите пользователя обслуживания и пользователя процесса контейнера. В новой среде конфигурация уже смонтирована только для чтения, но генератор работает как root.
Используйте Maintenance, открывающийся в /home/labex/project/report-desk. Терминал управляет только подготовленным report-renderer. При необходимости вернитесь через cd /home/labex/project/report-desk. sudo docker exec просит Docker выполнить команду внутри цели. id показывает числовой идентификатор пользователя (UID) и группы (GID):
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
UID 0 — root внутри контейнера, имеющий больше прав на доступные файлы, чем нужно приложению. Root контейнера не администрирует отдельную VM: контейнеры используют общее ядро хоста. Упражнение сокращает файловый доступ, а не все возможные риски контейнеров.
Подготовленный пользователь имеет UID/GID 1200:1200. Числовые ID работают без добавления именованной учётной записи в образ. Владелец каталога хоста должен разрешать этому пользователю запись. ls -ldn показывает сам каталог (-d), подробные права (-l) и числовые ID (-n):
ls -ldn output
Найдите drwxr-xr-x и владельца/группу 1200 1200. Владелец имеет rwx: чтение, запись и проход по каталогу. Остальные имеют r-x: чтение и проход, без записи. Среда подготовила каталог для нужного пользователя.
Создайте исходный документ знакомым POST-запросом. curl -fsS сообщает об HTTP-ошибках, а -X POST запрашивает бизнес-действие:
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
Отчёт работает, но создан UID 0. Откройте Document Desk, чтобы увидеть сохранённый документ; страница перечисляет реальные выходные файлы.
Выбор подготовленного пользователя
На этом шаге измените пользователя в описании запуска, сохраняя необходимый доступ к файловой системе. cat показывает скрипт:
cat launch.sh
sudo разрешает управление хостом. Отдельно --user определяет пользователя и группу приложения контейнера. 0:0 означает UID 0 и GID 0, а 1200:1200 выбирает подготовленного пользователя. Сохраните порт 8090, образ и оба пути монтирования. Строка конфигурации уже содержит dst=/config,readonly; выходное монтирование должно оставаться записываемым.
Откройте терминальный редактор:
nano launch.sh
Стрелками замените только --user 0:0 на --user 1200:1200. Сохраните через Ctrl+O, Enter, выйдите через Ctrl+X. Снова покажите файл:
cat launch.sh
Строка пользователя должна выглядеть так:
--user 1200:1200 \
Изменение описания не обновляет работающий процесс. Перед пересозданием явно задайте нужного владельца выходного каталога. chown задаёт числового владельца и группу; нужен sudo, поскольку эти ID отличаются от пользователя обслуживания хоста. Изменяется только каталог, а не все существующие файлы в нём:
sudo chown 1200:1200 output
Не делайте всё доступным только для чтения: создание документа требует записи в выходной каталог. Не выдавайте всем запись для обхода проблемы владельца; подготовленный владелец может писать с существующими правами каталога 755.
Пересоздание с сохранением бизнес-результата
На этом шаге примените нового пользователя и проверьте нормальную запись документов и защиту входных данных. Как раньше, удалите только целевой контейнер и запустите замену:
sudo docker rm -f report-renderer
bash launch.sh
При ошибке запуска исправьте launch.sh через nano, удалите неудачный контейнер той же командой и снова выполните скрипт. Данные хоста сохраняются. Проверьте работающего пользователя:
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
Подождите немного после запуска и создайте итоговый документ:
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied обычно означает неверного владельца выходного каталога или final.json, ранее созданный root. Исправьте каталог знакомой командой sudo chown 1200:1200 output. Если существует старый итоговый файл, sudo rm output/final.json удаляет только этот документ; запросите его снова. Read-only file system для /output означает, что выходное монтирование ограничено по ошибке: исправьте описание и пересоздайте контейнер.
Изучите созданный файл. ls -ln показывает числового владельца, cat — содержимое:
ls -ln output/final.json
cat output/final.json
Найдите владельца 1200, "uid": 1200, сумму 37 и Report for Harbor Books: 37 orders. Обновите Document Desk, чтобы увидеть файл. В конце подтвердите сохранение защиты конфигурации:
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
Этот отказ ожидаем. Пользователь без root-прав и монтирование только для чтения решают разные задачи: выбор UID сокращает права процесса, а режим монтирования запрещает запись конфигурации даже root внутри контейнера. Генератор продолжает выполнять настоящую задачу.
Резюме
Вы отделили обслуживание хоста от пользователя приложения, выбрали UID/GID 1200 и сохранили выходной каталог. Работающий процесс и новый документ теперь используют UID 1200, а запись в конфигурацию по-прежнему запрещена.
