Более чистый способ перезапустить daemontools сервисы
В нашем продукте мы создали сервисы с помощью daemontools. Один из моего сервиса похож на это,
/service/test/run
/service/test/log/run (has multilog command to log into ./main dir)
/service/test/log/main/..
Весь процесс и его каталоги принадлежат пользователю root. Теперь существует требование к защите измениться как это,
1. Service should run in non-root user.
2. Log main directory should be readable only to user and groups.
Для этого я должен изменить файл 'выполнения' в соответствии с каталогом 'журнала'. Также я должен изменить полномочия 'основного' каталога под ним.
Обратите внимание, что все эти файлы под '/service' принадлежали test-1.0-0.rpm. Когда я обновляю своего об/мин, он переопределяет существующий файл выполнения и получил ошибку как это,
multilog: fatal: unable to lock directory ./main: access denied
Я знаю, что мы не должны переопределять файл 'выполнения' во время выполнения. Я запланировал выполнить эти шаги в своем сценарии об/мин %post раздел,
//Stop service
svc -d /service/test/log
//Moving the main directory
mv /service/test/log/main /service/test/log/main_old
//Updated run file has code to create main with limited permissions.
//Start service
svc -u /service/test/log
В некоторых статьях они предложили воссоздать файл 'блокировки' под 'журналом / основной'. Есть ли какой-либо другой более чистый способ сделать это, не перемещая 'основной' каталог? В противном случае действительно ли безопасно пойти с вышеупомянутыми шагами?
1. Service should run in non-root user.
Достаточно просто. Вы должны скопировать определение службы в каталог служб в доме «пользователя». Например, допустим, вы создаете пользователя, мы назовем его niftyuser . Также предположим, что ваша служба называется niftyservice . Итак, вы скопируете определение службы в каталог, управляемый этим пользователем; для обсуждения (и не обязательно для того, чтобы вы этого захотели) предположим, что вы будете использовать домашний каталог niftyuser . Итак,
cp -Rav /etc/service/niftyservice /home/niftyuser/service/niftyservice
создаст определение службы. Затем вам нужно будет запустить сканирование службы в каталоге этого пользователя, но запущенное с учетными данными пользователя. Если бы вы написали его как сценарий, это выглядело бы примерно так:
#!/bin/sh
exec setuidgid niftyuser svscan /home/niftyuser/service
Результатом будет дерево служб, которым управляет этот пользователь. Обратите внимание, что сделав это скриптом, вы можете затем вставить поддерево вашего процесса, управляемого пользователем, в главное дерево процессов ... вы можете увидеть пример runit для , как это выглядит , как runit был вдохновлен daemontools.
2. Log main directory should be readable only to user and groups.
Честно говоря, я просто делаю / service / (имя-службы) / log / main символической ссылкой на реальный каталог, то есть / service / niftyservice / log / main указывает на / var / log / niftyservice . В сценарии выполнения для каталога журналов укажите в качестве цели ./ main ; это означает, что вы можете настроить определение один раз и перемещать ведение журнала по мере необходимости, просто изменив символическую ссылку. И, наконец, чтобы ответить на вопрос (2), вы должны установить права пользователя и группы для / var / log / niftyservice по мере необходимости и установить режим 775. Это позволит любому читать файлы, но только пользователь или группа могут писать им.