У меня есть демон foo. Мой сценарий инициализации /etc/init.d/foo начинает foo демон и хранит свой pid-файл в /var/run/foo.pid, что кажется стандартным местом. Так как /etc/init.d/foo должен запускаться как root, у него нет проблем с созданием и удалением pid-файлов в /var/run.
В foo демон - это действительно программа /usr/sbin/foo который предназначен для вызова как root в сценарии инициализации, но затем сразу же теряет свои привилегии непривилегированным foo пользователь. Однако я тоже хочу это /usr/sbin/foo программа для удаления своего pidfile при выходе из-за критической ошибки. Но поскольку он уже отказался от своих привилегий, у него больше нет возможности удалять файлы из /var/run каталог.
Мой нынешний подход - использовать seteuid вместо того setuid чтобы отказаться от моих привилегий, затем повторно поднять привилегии непосредственно перед выходом, чтобы я мог правильно удалить pidfile из /var/run. Тем не менее, я столкнулся с множеством проблем с различными библиотеками и внешними программами, которые выходят из строя при вызове с другим euid, чем uid.
Есть ли другой способ добиться этого? Я полагаю, что другой вариант - просто поместить мой pid-файл в каталог, доступный для записи как корню, так и foo пользователей. Но все остальные наши pid-файлы находятся в /var/run, включая pid-файлы других программ, которые работают от имени непривилегированных пользователей, поэтому я бы хотел поставить foo.pid файл и там.
Есть ли способ сделать это, кроме использования seteuid?
Не помещайте файл PID в /var/run/foo.pid, положи это в /var/run/foo/foo.pid и имеют /var/run/foo принадлежит пользователю foo и группа foo. Таким образом, вы можете удалить файл pid перед выходом, и вам не нужно повышать уровень привилегий.
Обратите внимание, однако, что это плохая практика безопасности, поскольку разрешение непривилегированному приложению искажать его файл откроет дыру в безопасности: представьте, что ваше приложение было взломано (в конце концов, какой смысл отбрасывать привилегии, если не ожидать, что приложение может быть атакованным?) - теперь злоумышленник обновляет файл pid и помещает туда, скажем, номер pid sshd. Теперь, когда общесистемные скрипты (запущенные от имени root) попытаются остановить ваше приложение, используя этот файл pid, они вместо этого отключат sshd. Это всего лишь пример, есть и другие способы злоупотребить вашей системой. В общем, файл pid должен быть создан перед Удаление привилегий и очистка файлов pid должны выполняться общесистемными скриптами. - Дмитрий Дмитриевич Хлебников
Еще лучше было бы переключиться на систему инициализации, такую как systemd или Upstart, которая не требует файлов PID для управления службами.
Вы можете разветвить новый процесс перед запуском вашего демона. Родительский процесс остается с привилегированным пользователем root. Дочерний процесс теряет свои привилегии до foo пользователь. Этот процесс выполняет настоящую работу демона.
Родительский процесс создаст файл PID после разветвления своего дочернего процесса и удалит его, когда его дочерний процесс завершится.
Заглянув в свою систему Ubuntu, я вижу, что некоторое установленное программное обеспечение создало каталоги в / var / run, принадлежащие пользователю без полномочий root, как предлагает jcollie.
Другой вариант - сделать так, чтобы pid-файл принадлежал пользователю без полномочий root и обнулить файл вместо его удаления.