Come possiamo consentire agli utenti non root di controllare un servizio system.d?


60

Con sysvinit, una sudoersvoce come questa sarebbe sufficiente:

%webteam cms051=/sbin/service httpd *

Ciò consentirebbe comandi come:

  • sudo service httpd status
  • sudo service httpd restart

Ora, con systemd, il nome del servizio è l'argomento finale. Vale a dire, il riavvio del servizio verrebbe eseguito con:

systemctl restart httpd.service

Naturalmente, ho pensato di definire il comando come systemctl * httpd.serviceavrebbe funzionato, ma ciò avrebbe permesso qualcosa di simile systemctl restart puppet.service httpd.serviceche non è l'effetto desiderato.

Considerato ciò, quale sarebbe il modo migliore per consentire agli utenti non root di controllare un system.dservizio? Questo non deve essere sudoers; forse una modifica del permesso del file può essere sufficiente?


Non tocco una sudoconfigurazione da un po ', ma non potresti semplicemente fare qualcosa del genere cms051=systemctl * httpd.service?
John WH Smith,

1
Ciò consentirebbe quindi di riavviare qualsiasi servizio. Avrei dovuto includere quel bocconcino nella domanda. Scusate.
Belmin Fernandez,

Risposte:


43

Basta aggiungere tutti i comandi necessari a sudoersseparatamente:

%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

Speravo di catturare tutti i comandi dell'unità, ma se devo specificarli in dettaglio, penso che sia quello che dovrò fare.
Belmin Fernandez,

9
lo stato non è utile, poiché qualsiasi utente può farlo
Dereckson

5
Che cosa è cms051?
Kevin il

1
Quindi cosa succederà se invoco il riavvio di systemctl http.service mariadb.service ;-)? Probabilmente anche mariadb verrà riavviato
Marek Wajdzik

1
@MarekWajdzik sudo non ammette argomenti aggiuntivi se uno non lo consente esplicitamente con *o schemi simili.
jofel

31

La risposta di @Jofel era esattamente ciò di cui avevo bisogno per ottenere una configurazione funzionante. Affermandolo per chiunque inciampare in questa domanda. Avevo bisogno di un modo per capistranoriavviare l'applicazione Ruby dopo la distribuzione dal mio computer locale. Ciò significa che avevo bisogno di un accesso senza password ai systemdservizi di riavvio . Questo è quello che ho e funziona meravigliosamente!

Nota : il mio utente e il mio gruppo sono chiamati deployer
Inserisci codice in un file personalizzato qui: /etc/sudoers.d/deployer
Codice:

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

Devo aggiungere che dopo aver effettuato l'accesso come utente deployernel caso, è necessario eseguire il systemctlcomando con sudo.
Muyiwa Olu,

8

Creare un alias di comando con i comandi a cui si desidera che abbiano accesso. Quindi assegnare il gruppo a tale alias di comando:

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

%webteam ALL=APACHE-SVC

È anche buona norma inserire qualsiasi modifica nel tuo /etc/sudoers.d/filename piuttosto che modificare direttamente il file sudoers. Assicurati di puntare al tuo .d / nomefile nei sudoers, che fanno comunque la maggior parte delle nuove distro. Posizionare queste 2 linee nei sudoer dovrebbe fare il trucco:

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

Nota: Quel # davanti al incluso non è un commento. Deve rimanere.


Come aggiungere la possibilità di eseguire l'arresto / avvio / riavvio senza inserire la password?
Nikolay Baranenko,

Migliore risposta IMO. Tutti dovrebbero aggiungere un alias di comando e lavorare con questo.
DASKAjA,

6

È più sicuro classificarli come suggerisce Jofel .

Se volessi consentire a qualcuno di usare un sottoinsieme limitato delle abilità di un comando, non mi fiderei dei caratteri jolly in una riga sudoers per farlo. Anche se il linguaggio era più espressivo dei globs di shell, ci sono troppi casi angolari da tenere traccia.

La service httpd *linea " " è relativamente sicura perché (verifica questo :) serviceha solo un utile flag ( --status-all) che non fa nulla di particolarmente sensibile, e (verifica anche questo :) /etc/init.d/httpdaccetterà solo le linee di comando che vuoi consentire.

Se ci sono così tante combinazioni che elencarle diventa imbarazzante, probabilmente dovresti chiederti cosa stai facendo. Ma potresti dare loro accesso a uno script helper scritto con cura che esegue il comando per loro (molto simile /etc/init.d/http). Anche in questo caso dovresti essere il più preciso ed esplicito possibile per elencare esattamente quali comandi e opzioni sono consentiti e non passare alcun input dell'utente direttamente al comando target.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.