web-dev-qa-db-fra.com

systemd: accorder à un utilisateur non autorisé l'autorisation de modifier un service spécifique

J'exécute un serveur de jeu privé sur une boîte Linux sans tête. Parce que je ne suis pas un idiot, ledit serveur fonctionne comme son propre utilisateur non privilégié avec les droits d'accès minimums nécessaires pour télécharger les mises à jour et modifier la base de données mondiale.

J'ai également créé un fichier d'unité systemd pour démarrer, arrêter et redémarrer correctement le serveur en cas de besoin (pour lesdites mises à jour, par exemple).

Cependant, afin d'appeler réellement systemctl ou service <game> start/stop/restart J'ai encore besoin de me connecter en tant qu'utilisateur root ou Sudo.

Existe-t-il un moyen de dire à systemd que pour le <game> service, utilisateur non privilégié gamesrv est autorisé à exécuter les commandes de démarrage/arrêt/redémarrage?

linuxsystemd
21
Shadur

Je peux penser à deux façons de procéder:

L'une consiste à faire du service un service utilisateur plutôt qu'un service système.

Au lieu de créer une unité système, l'unité systemd sera placée dans le répertoire personnel de l'utilisateur du service, à $HOME/.config/systemd/user/daemon-name.service. Le même utilisateur peut alors gérer le service avec systemctl --user <action> daemon-name.service.

Pour permettre à l'unité utilisateur de démarrer au démarrage , root doit activer la persistance pour le compte, c'est-à-dire Sudo loginctl enable-linger username. L'unité doit également être WantedBy=default.target.

L'autre moyen consiste à autoriser l'accès de l'utilisateur à gérer l'unité centrale via PolicyKit. Cela nécessite systemd 226 ou supérieur (et PolicyKit> = 0.106 pour les fichiers JavaScript rules.d - vérifiez avec pkaction --version).

Vous devez créer un nouveau fichier de configuration PolicyKit, par exemple /etc/polkit-1/rules.d/57-manage-daemon-name.rules qui vérifie les attributs que vous souhaitez autoriser. Pour exemple :

// 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;
    }
});

L'utilisateur nommé peut alors gérer le service nommé avec systemctl et sans utiliser Sudo.

38
Michael Hampton

Sudo est fait pour ça. Modifiez votre /etc/sudoers fichier avec visudo pour ajouter un Cmd_alias pour les commandes que vous souhaitez que l'utilisateur non privilégié puisse utiliser:

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

et ajoutez une ligne pour permettre à l'utilisateur non privilégié d'utiliser les commandes définies avec l'alias comme ceci:

unprivileged_user ALL=(ALL) NOPASSWD: GAME_CMDS

En savoir plus documentation sur le sujet des différents paramètres de la commande Sudo.

Vous devrez peut-être installer le package Sudo pour que Sudo soit disponible sur votre système.

12
Henrik Pingel

Vous pouvez associer Sudo à un accès équivalent à root, mais il peut également être utilisé pour autoriser un utilisateur root spécifique à accéder à un ensemble spécifique et limité de commandes.

Comment cela a déjà été répondu sur Server Fault, à [ Donner accès à un ensemble de commandes à un utilisateur non root sans Sudo accès à un ensemble de commandes à un utilisateur non root sans Sudo) .

L'utilisation de PolicyKit est encore rare. L'utilisation d'une "unité utilisateur" systemd devrait fonctionner correctement, mais historiquement, votre objectif a été atteint à plusieurs reprises en utilisant la capacité de Sudo pour permettre à un utilisateur d'exécuter des commandes spécifiques en tant que root.

1
Mark Stosberg