43

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?

Shadur
  • 1,297
  • 1
  • 10
  • 20
  • Which version of PolicyKit / distribution? Debian (and derivatives) are on [an older version that requires a different configuration file format](https://lists.debian.org/debian-user/2016/01/msg00209.html). – Gert van den Berg Nov 20 '18 at 13:01

3 Answers3

71

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • User mode and `loginctl` worked. – Shadur Mar 29 '17 at 14:30
  • @MichaelHampton In fact, and this is great! I found it really strange that I never found this 'tip' anywhere because it seems to me a pretty useful use-case. – daks May 23 '18 at 12:13
  • which of the two approaches are we upvoting here? – mnagel Oct 17 '18 at 17:29
  • @mnagel Which one helped you? Which one did you learn something from? Either? Both? It doesn't matter, you can upvote if you feel like it. – Michael Hampton Oct 17 '18 at 19:27
  • Clarification to the first option: Don't forget to `enable` this user service: `systemctl --user enable `. Found from: https://superuser.com/questions/1025091/start-a-systemd-user-service-at-boot#comment2062994_1028180 – Dionysius Jan 24 '22 at 13:38
28

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.

Henrik Pingel
  • 8,676
  • 2
  • 24
  • 38
  • I know how to use sudo, yes. I was wondering if there was an option that'd let me skip even that since in this case the first thing the `systemd` unit file does is specify that it needs to be run as `gamesrv`. – Shadur Mar 28 '17 at 17:38
  • 1
    I was able to modify the sudoers file, but I don't understand what this translates to on the command line. Do I just write `sudo GAME_CMDS` while logged in as unprivileged_user? – devaent Apr 09 '21 at 21:39
  • in this example `GAME_CMDS` is just an alias inside the sudoers file. With both lines inside the sudoers file it translate to: unprivileged user can execute sudo systemctl start minecraft of whatever you defined in the alias. – Henrik Pingel Jul 07 '21 at 14:59
2

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.

Community
  • 1
Mark Stosberg
  • 3,771
  • 23
  • 27