Allow a non-root user to control the systemctl of a service

Using root users to control all services may not be desired, although it is the default. We can use a particular non-root user to control a service. To do this we must perform the following steps:

Note: Editing sudoers files, both /etc/sudoers and any files under /etc/sudoer.d/, should always be done with the visudo editor command, never directly with vim, cat, and other commands. The visudo command will open an editor, and, after you've edited the file, when you save and exit, it will check the contents to ensure that there are no syntax errors that could break sudo usage on the system. See man visudo for its full documentation.

1. Open or create a file under /etc/sudoers.d directory, using the visudo command. In this example we will create a /etc/sudoers.d/pgadm file which will then work for a user named pgadm:

visudo -f /etc/sudoers.d/pgadm

2. Add the following in the file created:

# Allow pgadm user to control systemctl
Defaults:pgadm !requiretty
pgadm ALL = NOPASSWD: /bin/systemctl [stop|start|restart|reload|status]* [postgres|edb]*
pgadm ALL = NOPASSWD: /usr/bin/systemctl [stop|start|restart|reload|status]* [postgres|edb]*

3. Logout
4. Login again with the pgadm user
5. The user would be able to run sudo systemctl [stop|start|restart|reload|status]* [postgres|edb]* without being asked for a password.

Alternatively, a group can be created and users can be assigned to that. In this example we will create the dba group and configure the file accordingly.

1. Create the new group using the following command:

sudo groupadd dba

2. Add the user to the group. From the previous example, we will add the user pgadm to the dba group:

usermod -a -G dba pgadmin

3. Add the following to a file under /etc/sudoers.d directory, using the visudo command. In this example we will use the file dba:

visudo -f /etc/sudoers.d/dba

4. Add the following in the file created. In this example we will use the dba group:

# Allow dbadmin group to control systemctl
Defaults exempt_group=dba
%dba ALL = NOPASSWD: /usr/bin/systemctl [stop|start|restart|reload|status]* [postgres|edb]*,! /usr/bin/systemctl *able*

5. Logout
6. Login again with the user belonging to the group
7. The user would be able to run sudo systemctl [stop|start|restart|reload|status]* [postgres|edb]* without being asked for a password.

If it is required that the user is not able to enable or disable the service, we can add the following line to the file:

! /usr/bin/systemctl *able*

Services managed by systemd can be subjected to a set of rules implemented by Polkit . For purposes relating to local configuration of a single system, only /etc/polkit-1/rules.d should be used. In the polkit documentation there are multiple examples that can be used as a reference. It can be accessed here - Polkit Documentation.

The addRule() method is used for adding a function that may be called whenever an authorization check for action and subject is performed. Functions are called in the order they have been added until one of the functions returns a value. So, to add an authorization rule that is processed before other rules, put it in a file in /etc/polkit-1/rules.d with a name that sorts before other rules files, for example /etc/polkit-1/rules.d/00-dba.rules. This file will have a rule allowing users belonging to the dba group to use all actions on services with names beginning with postgres, like the following example:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
/^postgres.*\.service$/.test(action.lookup("unit")) &&
subject.isInGroup("dba"))
{
return polkit.Result.YES;
}
})

If EPAS is being used, it would look like this:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
/^edb-as*.service$/.test(action.lookup("unit")) &&
subject.isInGroup("dba"))
{
return polkit.Result.YES;
}
})

Note: the lookup on the unit name is not available in RHEL 7's version of systemd, as explained in the Red Hat Solutions Website. If you need a granular control of the service, please use a newer RHEL version.