Je peux penser à deux façons de faire cela :
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 sous le répertoire personnel du service utilisateur, à $HOME/.config/systemd/user/daemon-name.service. Le même utilisateur peut ensuite gérer le service avec systemctl --user daemon-name.service.
Pour permettre à l'unité utilisateur de démarrer au démarrage, root doit activer la fonctionnalité linger pour le compte, c'est-à-dire sudo loginctl enable-linger nom_utilisateur. L'unité doit également être WantedBy=default.target.
L'autre façon est de permettre à l'utilisateur d'accéder à la gestion de l'unité système 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). Notez que Debian a délibérément retenu PolicyKit pour une version presque vieille de dix ans, la version 0.105, qui ne prend pas en charge cette fonctionnalité, apparemment en raison de l'opinion personnelle de quelqu'un, et ni lui ni les distributions dérivées de lui (comme Ubuntu) ne peuvent utiliser cette méthode.
Vous créeriez 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. Par exemple :
// Autoriser alice à gérer example.service;
// sinon, retour à l'autorisation implicite.
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 ensuite gérer le service nommé avec systemctl et sans utiliser sudo.
