web-dev-qa-db-fra.com

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

Avec sysvinit, une entrée sudoers 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 le dernier argument. C'est-à-dire que le redémarrage du service se ferait avec:

systemctl restart httpd.service

Naturellement, je pensais que définir la commande comme systemctl * httpd.service fonctionnerait mais cela permettrait quelque chose comme systemctl restart puppet.service httpd.service ce qui n'est pas l'effet souhaité.

Cela étant considéré, quelle serait la meilleure façon de permettre aux utilisateurs non root de contrôler un system.d service alors? Cela n'a pas besoin d'être sudoers; peut-être qu'un changement d'autorisation de fichier peut être suffisant?

rhelsudosystemdservicesnot-root-user
64
Belmin Fernandez

Ajoutez simplement toutes les commandes nécessaires à sudoers sé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
45
jofel

La réponse de @ jofel était exactement ce dont j'avais besoin pour obtenir une configuration fonctionnelle. Présenter cela à quiconque trébuche sur cette question. J'avais besoin d'un moyen pour que capistrano redémarre mon Ruby après le déploiement depuis ma machine locale. Cela signifie que j'avais besoin d'un accès sans mot de passe pour redémarrer les services systemd. ce que j'ai et ça marche à merveille!

Remarque: mon utilisateur et mon groupe s'appellent deployer
Mettez 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
33
BoomShadow

Créez un alias de commande avec les commandes auxquelles vous souhaitez qu'ils aient accès. Attribuez ensuite 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 votre /etc/sudoers.d/filename plutôt que de modifier directement le fichier sudoers. Assurez-vous de pointer vers votre .d/nom de fichier dans les 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 # en face de l'ir inclus n'est pas un commentaire. Cela doit rester.

8
Rich

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 dans une ligne sudoers pour le faire. Même si le langage était plus expressif que les globes Shell, il y a tout simplement trop de cas d'angle à suivre.

La ligne "service httpd *" Est relativement sûre car (vérifiez ceci :) service n'a qu'un seul indicateur utile (--status-all) Qui ne fonctionne pas ' ne faites rien de particulièrement sensible, et (vérifiez cela aussi :) /etc/init.d/httpd n'acceptera que les lignes de commande que vous souhaitez autoriser.

S'il y a tellement de combinaisons que les énumérer devient gênant, vous devriez probablement vous demander ce que vous faites. Mais vous pouvez leur donner accès à un script d'aide soigneusement écrit qui exécute la commande pour eux (un peu comme /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 utilisateur directement à la commande cible.

6
Jander