Restarting a Systemd Service Only With a Specific User

1. Overview

systemd is a system and service manager for Linux operating systems that provides a standard for initializing and managing services. While it’s common to manage systemd services at the system level using the root user, there are scenarios where we’d want specific users to restart services without requiring root privileges.

In this tutorial, we’ll look at how to restart a systemd service as a specific user.

2. systemd and Linux Permissions in Brief

When a service is controlled by systemd, it typically runs under the root user because service management normally requires elevated privileges. For example, restarting a service like nginx or ssh involves stopping and starting processes that affect the system, and this is usually restricted to users with root privileges.

To restart a systemd service with a specific user, we need to work within the constraints of both systemd and Linux permissions. Restarting a service typically requires elevated privileges (root or via sudo), but we can structure a process such that only a specific user can restart the service.

systemd is the init system used in many modern Linux distributions for managing system services. It’s responsible for starting, stopping, and managing services. We usually use the systemctl command to interact with these services. The systemctl command is typically restricted to root users or users with sudo privileges.

Services are defined in .service files, typically in /etc/systemd/system/ for system-wide services or ~/.config/systemd/user/ for user-specific services.

Due to different circumstances and requirements, we might run into scenarios where we need to grant a non-root user the ability to restart a service without giving them full sudo privileges.

For instance, this could be useful for:

• A development environment where only a service administrator should restart services
• Limiting access to critical production services so only authorized personnel can control them

3. Modifying systemd Service to Run as a Specific User

In this section, we’ll create a simple systemd service that we’ll use as an example. Alternatively, we can use any existing systemd service of our choice.

3.1. Creating User-Specific Systemd Services

Now let’s create a user-specific systemd service. This allows a specific user to control the service without root or sudo privileges. Each user has their systemd services stored in ~/.config/systemd/user/.
Firstly, let’s create our file in this directory:

$ mkdir -p ~/.config/systemd/user/

Next, we create the service file for our service:

$ vi ~/.config/systemd/user/systeminfo.service

Now, let’s add the following:

[Unit]
Description=My computer information
[Service]
User=kali
WorkingDirectory=/usr/local/bin
ExecStart=/usr/local/bin/systeminfo.sh
[Install]
WantedBy=multi-user.target

Optionally, we can transfer our file to this folder.

For this example, we’ll use a service file we created, it’s owned by our default user kali:

$ ls -l .config/systemd/user/systeminfo.service
-rw-rw-r-- 1 kali kali 224 Sep 15 10:26 .config/systemd/user/systeminfo.service

In our service file, we’ve specified that kali is the only user allowed to run this service. This allows the user kali to perform all actions including restart. Any other user can not run or restart this service.

If we try to restart or stop the systeminfo.service using a different user, it won’t run or it will throw an error similar to this:

$ systemctl --user restart systeminfo
Failed to connect to bus: No medium found

3.2. Granting Restart Permission Using sudoers

The sudo command is widely used to allow users to perform tasks that require elevated privileges. By configuring sudo properly, we can allow specific users to execute some actions without granting them unrestricted access to the system.

For instance, to allow a specific user to restart a systemd service, we need to edit the /etc/sudoers file to grant limited permission. This file controls which users can run specific commands as root without a password.

Next, to modify the sudoers file safely, we use the visudo command, which validates the syntax before applying changes:

$ sudo visudo

Let’s add the following line at the end of the file to allow a specific user (for this case we’ll use south) to restart the systeminfo.service without needing a password:

south ALL=NOPASSWD: /bin/systemctl restart nginx.service

The directive above means:

• south is the user who should restart the service.
• The NOPASSWD directive allows south to restart the service without being prompted for a password.
• Following, the /bin/systemctl restart nginx.service restricts south to only restarting this particular service.

Let’s save and close the file then test if the configuration works.

For this example, we’ll use nginx. Firstly, we’ll log in as a different user (west), stop the service, and check its status:

$ sudo systemctl stop nginx

Following, let’s switch to south and try other commands including restart:

From the image above we’ve tested if our configuration works. Firstly, we stopped the nginx.service using wests’s account which has sudo privileges.

Next, we switched to south’s account where we tried to start and stop the nginx.service but failed because we lacked the necessary permissions.

Lastly, we restarted the service and it didn’t show any error.

4. Using Polkit

As part of an ongoing effort to enhance Linux system security while improving flexibility, Polkit (PolicyKit) was introduced around 2006. Before that, privilege escalation was binary: a user either had superuser privileges or didn’t. As a result, Polkit was created to address the problem of giving users more access than they needed. Thus reducing mistakes or security risks by allowing administrators to control permissions more precisely.

Polkit is a framework for defining and handling authorizations in Linux-based systems. Initially introduced by Red Hat, Polkit allows us to manage privileges and grant or restrict certain operations without requiring root access.

It acts as a mediator between the system and unprivileged processes, enabling users to perform specific administrative tasks that normally require superuser privileges, but in a controlled manner. Currently, Polkit has a broader use across different Linux distributions for securing various administrative operations.

4.1. How Polkit Works

Polkit uses a central daemon, polkitd, that listens for requests to perform privileged actions. When an application or user attempts to do something that requires elevated privileges (like restarting a service), Polkit checks its policy configuration to see if the action is allowed based on the user’s permissions.

In Polkit, definitions are divided into two types:

• We define actions in XML .policy files which are located in /usr/share/polkit-1/actions/
• Authorization rules defined in Javascript .rules files situated in either /usr/share/polkit-1/rules.d for 3rd party packages or /etc/polkit-1/rules.d for local configuration

These files dictate which actions require authentication and under what conditions. We can set rules based on user groups, individual users, or specific conditions like network status.

4.2. Limiting a User to Restart a Specific Systemd Service

To restrict a user to restarting only a specific systemd service, we need to create or modify Polkit rules.

Firstly, let’s assume we have a systemd service called systeminfo.service. To allow south to restart this service while preventing access to others let’s edit the /etc/polkit-1/rules.d/:

$ sudo vi /etc/polkit-1/rules.d/

Now let’s add the following lines:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "systeminfo.service" &&
        subject.isInGroup("kali")) {
        return polkit.Result.YES;
    }
});

This rule checks if the action requested is related to systemd units (e.g. restarting a service). Subsequently, it checks if the specific unit is systeminfo.service, and if the user belongs to the kali group. Finally, if the user meets all conditions, Polkit allows the action.

Following, let’s reload Polkit

$ systemctl restart polkit

We can then proceed to restart the service:

$ systemctl restart systeminfo.service

Alternatively, we can use the .policy files. For example, let’s say we want to restrict the users who can restart nginx.

Firstly, we need to create a .policy file that defines the action of restarting the nginx service. The file will specify that only authorized users (south) can execute this action:

$ vi /usr/share/polkit-1/actions

Now let’s add the following specifications:

<policyconfig>
  <action id="org.freedesktop.systemd1.manage-units.restart-nginx">
    <description>Restart the nginx service</description>
    <defaults>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>
</policyconfig>

Next, let’s assign specific users permission to restart the nginx service by editing the Polkit rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units.restart-nginx" &&
        subject.user == "kali") {
        return polkit.Result.YES;
    }
});

5. Conclusion

In this tutorial, we’ve looked at how we can restrict a user to only start a specific service. By carefully configuring the sudoers file, we can restrict the ability to restart a systemd service to a specific user without giving them full access. Additionally, we also looked at how to create a user-specific service file and how to configure Polkit to restrict actions users perform.

Lastly, we also need to test permissions, review user access regularly, and ensure additional security measures are set up such that each user only accesses and performs actions they need.