Немного контекста ...
У меня есть несколько устаревших сценариев инициализации System V, которые были преобразованы в файлы конфигурации модуля Systemd для RedHat 7. Проблемы с внезапным завершением пользовательских процессов, запущенных в user.slice, привели меня к открытию, что systemd / pam на RedHat 7 требует, чтобы мой сценарий использовал бегун для переключения пользователя (если он запущен как root) или Пользователь = чтобы убедиться, что они начнутся так как правильный пользователь. Теперь, чтобы убедиться, что systemd управляет моим демоном и запускает службу при перезагрузке, а также чтобы мои законные пользователи также могли запускать службу, у меня есть три варианта:
systemctl --user) контролировать этоsudo systemctl start name.serviceИтак, вернемся к вопросу ...
Является судо все еще хороший способ предоставить моему пользователю права на управление службами для RedHat 8? Или мне следует использовать PolicyKit, как указано в systemd: предоставить непривилегированному пользователю разрешение на изменение одной конкретной службы
Спасибо. Фрэнк
Правила PolicyKit - лучшее решение.
Пользовательский блок полностью находится под контролем пользователя. Однако из-за отсутствия прав он не может работать как демон-пользователь с опцией «Пользователь».
Системный администратор должен запустить системную службу с правами root. Хотя можно делегировать с помощью sudo, необходимо позаботиться о конкретных правилах sudo или сценариях, чтобы не предоставлять ненужный привилегированный доступ произвольным командам. И у пользователей появляется ненужная привычка добавлять sudo к systemctl.
PolicyKit может предоставить пользователю доступ к системному модулю. Запуск от имени пользователя работает. Переход к корневому доступу не предоставляется конечному пользователю. Он также работает для других клиентов API-интерфейса управления модулями, а не только для systemctl.