Запуск службы systemd с RootDirectory= и доступом к двоичным файлам /bin
Не полагайтесь на серверы, не находящиеся под вашим контролем, для воспроизведения определенного состояния системы. Даже если серверы Debian довольно надежны, никогда не знаешь, что может случиться в будущем. Это особенно актуально для других репозиториев, которые вы можете использовать.
Вам следует поддерживать собственное зеркало, чтобы получить воспроизводимые состояния системы. Таким образом, у вас может быть даже рабочее состояние для ваших обычных систем и несколько тестовых состояний для новых конфигураций.
Средство управления репозиторием aptly может создавать зеркала репозиториев. Вы можете выбирать пакеты для зеркалирования, создавать моментальные снимки содержимого репозитория в определенные моменты времени и объединять несколько зеркал или моментальных снимков в один репозиторий. Таким образом, вы можете полностью воспроизвести состояния системы.
Чтобы ответить на ваш вопрос напрямую:
how to properly execute a service with external dependencies outside of the chroot using RootDirectory.
Вы не можете. Если что-то находится в chroot-тюрьме, оно не может получить доступ ни к чему снаружи, включая двоичные файлы и библиотеки. Но у вас все еще есть способы защитить вашу систему.
Takes a directory path relative to the host's root directory (i.e. the root of the system running the service manager). Sets the root directory for executed processes, with the chroot(2) system call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in the chroot() jail.
Если вы установите RootDirectory=/srv/http, то при вызове /server.pyон попытается выполнить /usr/bin/python, но потерпит неудачу, потому что не может найти этот путь. Даже если бы вы могли сделать что-то вроде ExecStartPre=/bin/cp /usr/bin/python /src/http/usr/bin/python, у вас все равно возникнут проблемы при попытке import flaskили import pyramid, так как эти библиотеки не установлены в вашем chroot. Я провел тест с настройкой, подобной вашей, и без хорошего шебанга получил ту же ошибку, что и вы.
Вот три варианта:
Дайте вашему chroot все, что ему нужно. Если вы работаете в системе, основанной на Debian -, то
debootstrap— отличный инструмент для настройки,deboostrap buster /srv/httpдолжен работать. Он установит базовую систему, после чего вы сможетеsudo chroot && apt install python python-flaskили что-то еще, что вам нравится внутри.Используйте встроенные параметры -для песочницы вашего сервиса вместо его chroot. В частности:
RemoveIPC=trueиPrivateTmp=true. Это гарантирует, что время жизни объектов IPC и временных файлов, созданных исполняемым процессом, привязано к времени выполнения службы. Поскольку/tmpи/var/tmpобычно являются единственными мировыми -доступными для записи каталогами в системе, это гарантирует, что устройство не сможет оставить файлы после завершения работы.NoNewPrivileges=trueиRestrictSUIDSGID=true.Это гарантирует, что запущенные процессы не смогут воспользоваться преимуществами или создать файлы или каталоги SUID/SGID.ProtectSystem=strictиProtectHome=read-onlyзапрещают службе запись в любое место в вашей файловой системе (исключениями являются/dev//proc/и/sys/. Чтобы разрешить службе запись в определенные каталоги, они должны быть разрешены -в списке с помощьюReadWritePaths=.RuntimeDirectory=для назначения службе каталога времени выполнения, который принадлежит пользователю службы и автоматически удаляется при завершении работы системы.
- Вы можете заменить все, что я сказал во втором шаге, одной строкой
DynamicUser=true. Здесь есть хорошее объяснение разработчика
В любом случае, если вы не используете User=или DynamicUser=, вы должны это сделать. Это не позволит вашей службе быть rootи иметь права на чтение /etc/shadowили других секретов.
Мне очень нравится вариант 3. Его включение действительно защищает вашу систему от служб.