Home / server / Questions / 841099
Accepted
Shadur
Asked: 2017-03-29 09:24:11 +0800 CST

systemd: Grant an unprivileged user permission to alter one specific service

  • 772

I'm running a private game server on a headless linux box. Because I'm not an idiot, said server is running as its own unprivileged user with the bare minimum access rights it needs to download updates and modify the world database.

I also created a systemd unit file to properly start, stop and restart the server when needed (for said updates, for example).

However, in order to actually call systemctl or service <game> start/stop/restart I still need to log in as either root or a sudo capable user.

Is there a way to tell systemd that for the <game> service, unprivileged user gamesrv is permitted to run the start/stop/restart commands?

linux

3 Answers

  1. Best Answer

    I can think of two ways to do this:

    One is by making the service a user service rather than a system service.

    Instead of creating a system unit, the systemd unit will be placed under the service user's home directory, at $HOME/.config/systemd/user/daemon-name.service. The same user can then manage the service with systemctl --user <action> daemon-name.service.

    To allow the user unit to start at boot, root must enable linger for the account, i.e. sudo loginctl enable-linger username. The unit must also be WantedBy=default.target.

    The other way is by allowing the user access to manage the system unit via PolicyKit. This requires systemd 226 or higher (and PolicyKit >= 0.106 for the JavaScript rules.d files – check with pkaction --version). Note that Debian has deliberately held back PolicyKit to a nearly decade old version 0.105 which does not support this functionality, apparently because of one person's personal opinion, and neither it nor distributions derived from it (like Ubuntu) can use this method.

    You would create a new PolicyKit configuration file, e.g. /etc/polkit-1/rules.d/57-manage-daemon-name.rules which checks for the attributes you want to permit. For example:

    // Allow alice to manage example.service;
// fall back to implicit authorization otherwise.
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "example.service" &&
        subject.user == "alice") {
        return polkit.Result.YES;
    }
});

    The named user can then manage the named service with systemctl and without using sudo.

    • 71

  2. sudo is made for that. Edit your /etc/sudoers file with visudo to add a Cmd_alias for the commands you want the unprivileged user to be able to use:

    # game server commands
Cmnd_Alias GAME_CMDS = /usr/bin/systemctl start <game service>, /usr/bin/systemctl stop <game service>

    and add a line to allow the unprivileged user to use the commands defined with the alias like this:

    unprivileged_user ALL=(ALL) NOPASSWD: GAME_CMDS

    Read some more documentation on the topic for the various parameters of sudo command.

    You may need to install sudo package to have sudo available on your system.

    • 28

  3. You may associate sudo with providing access equivalent to root, but it can be also be used to allow a specific user root access for a specific, limited set of commands.

    How do that has already been answered on Server Fault, at [Giving access of a set of commands to a non-root user without sudo access of a set of commands to a non-root user without sudo).

    Using PolicyKit is still uncommon. Using a systemd "user unit" should work fine, but historically your goal has been met many times by using the ability of sudo to allow a user to run specific commands as root.

    • 2