Comment pouvons-nous permettre aux utilisateurs non root de contrôler un service system.d?

60

Avec sysvinit, une sudoersentrée comme celle-ci suffirait:

%webteam cms051=/sbin/service httpd *

Cela permettrait des commandes telles que:

sudo service httpd status
sudo service httpd restart

Maintenant, avec systemd, le nom du service est l'argument final. Par exemple, le redémarrage du service se ferait avec:

systemctl restart httpd.service

Naturellement, j’ai pensé définir la commande de la manière systemctl * httpd.servicequi fonctionnerait, mais qui permettrait d’obtenir quelque chose comme systemctl restart puppet.service httpd.servicece qui n’est pas l’effet recherché.

Cela envisagé, quel serait le meilleur moyen de permettre aux utilisateurs non root de contrôler un system.dservice? Cela n'a pas besoin d'être sudoers; peut-être qu'un changement d'autorisation de fichier sera suffisant?

— Belmin Fernandez
source

Je n'ai pas touché à une sudoconfiguration depuis un moment, mais ne pourriez-vous pas faire quelque chose du genre cms051=systemctl * httpd.service?

— John WH Smith

1

Cela vous permettrait alors de redémarrer n’importe quel service. J'aurais dû inclure cette friandise dans la question. Pardon.

— Belmin Fernandez

43

Ajoutez simplement toutes les commandes nécessaires sudoersséparément:

%webteam cms051=/usr/bin/systemctl restart httpd.service
%webteam cms051=/usr/bin/systemctl stop httpd.service
%webteam cms051=/usr/bin/systemctl start httpd.service 
%webteam cms051=/usr/bin/systemctl status httpd.service

— jofel
source

J'espérais capturer toutes les commandes de l'unité, mais si je dois les détailler, alors je suppose que c'est ce que je devrai faire.

— Belmin Fernandez

9

statut n'est pas utile, comme n'importe quel utilisateur peut le faire

— Dereckson

5

C'est quoi cms051?

— kevin

1

Donc, que se passera-t-il si j'appelle systemctl restart http.service mariadb.service ;-)? Mariadb sera probablement relancé aussi

— Marek Wajdzik

1

@MarekWajdzik sudo n'autorise pas d'argument supplémentaire s'il n'est pas explicitement autorisé avec *des modèles similaires.

— Jofel

31

La réponse de @ jofel était exactement ce dont j'avais besoin pour obtenir une configuration opérationnelle. C'est pour ceux qui trébuchent sur cette question. J'avais besoin d'un moyen de faire capistranoredémarrer mon application Ruby après le déploiement à partir de ma machine locale. Cela signifie que j'avais besoin d'un accès sans mot de passe pour le redémarrage des systemdservices. C’est ce que j’ai et cela fonctionne à merveille!

Remarque : mon utilisateur et mon groupe s'appellent deployer
Mettre le code dans un fichier personnalisé ici: /etc/sudoers.d/deployer
Code:

%deployer ALL= NOPASSWD: /bin/systemctl start my_app
%deployer ALL= NOPASSWD: /bin/systemctl stop my_app
%deployer ALL= NOPASSWD: /bin/systemctl restart my_app

— BoomShadow
source

Je dois ajouter qu'après la connexion en tant qu'utilisateur deployerdans le cas, vous devez exécuter la systemctlcommande avec sudo.

— Muyiwa Olu

8

Créez un alias de commande avec les commandes auxquelles vous souhaitez qu’ils aient accès. Puis assignez le groupe à cet alias de commande:

Cmnd_Alias APACHE-SVC = /usr/bin/systemctl stop httpd, /usr/bin/systemctl start httpd, /usr/bin/systemctl restart httpd

%webteam ALL=APACHE-SVC

Il est également recommandé de placer les modifications dans /etc/sudoers.d/filename plutôt que de modifier directement le fichier sudoers. Assurez-vous de bien indiquer votre nom de fichier .d / filename dans sudoers, ce que la plupart des nouvelles distributions font de toute façon. Placer ces 2 lignes dans vos sudoers devrait faire l'affaire:

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

Remarque: Ce # devant le includeir n'est pas un commentaire. Ça doit rester.

— Riches
source

Comment ajouter une chance d'exécuter stop / start / restart sans entrer le mot de passe?

— Nikolay Baranenko

Meilleure réponse IMO. Tout le monde devrait ajouter un alias de commande et travailler avec cela.

— DASKAjA

6

Il est plus sûr de les détailler, comme le suggère jofel .

Si je voulais permettre à quelqu'un d'utiliser un sous-ensemble limité des capacités d'une commande, je ne ferais pas confiance aux caractères génériques d'une ligne sudoers pour le faire. Même si le langage était plus expressif que les globes de shell, il y a tout simplement trop de cas en suspens à suivre.

La service httpd *ligne " " est relativement sûre car (cochez cette case :) servicen'a qu'un indicateur utile ( --status-all) qui ne fait rien de particulièrement sensible, et (cochez cette case aussi :) /etc/init.d/httpdn'acceptera que les lignes de commande que vous souhaitez autoriser.

S'il y a tellement de combinaisons que les énumérer devient difficile, vous devriez probablement vous demander ce que vous faites. Mais vous pouvez leur donner accès à un script d'assistance soigneusement écrit qui exécute la commande pour eux (très similaire /etc/init.d/http). Même dans ce cas, vous devez être aussi précis et explicite que possible pour répertorier exactement les commandes et les options autorisées, et ne transmettre aucune entrée d'utilisateur directement à la commande cible.

— Jander
source