0

Just a bit of context...

I got some legacy System V Init script that were converted to Systemd unit configuration files for RedHat 7. Problems with abrupt termination of user processes running in the user.slice led me to the discovery that systemd/pam on RedHat 7 require my script to use runuser to switch user (if they are started as root) or User= to make sure they start as the right user. Now to make sure that systemd controls my daemon and starts the service on reboot and to make sure my legitimate users can start the service as well, it seems like I have three options:

  1. Define a "user" service instead (and use systemctl --user) to control it
  2. Allow my user to start/stop the service sudo sudo systemctl start name.service
  3. Allow my user to start/stop the service with PolicyKit

So back to the question...

Is sudo still a good way to give my user privileges to control services for RedHat 8? Or should I use PolicyKit as indicated in systemd: Grant an unprivileged user permission to alter one specific service

Thank you. Frank

Francozen
  • 163
  • 5

1 Answers1

0

PolicyKit rules are a better solution.

User unit is completely under the control of the user. However, due to lack of privilege it can't run as a daemon user with a User option.

Starting a system service as root is what a sysadmin would do. While possible to delegate with sudo, would need to take care with specific sudo rules or scripting to not give unnecessary privileged access to arbitrary commands. And it gets users in the unnecessary habit of prefixing sudo to systemctl.

PolicyKit can grant a user access to a system unit. Run as User works. Escalation to root is not exposed to the end user. It also works for other clients of the manage-units API, not just systemctl.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32