sudo non funziona su alcuni comandi

Ho un problema piuttosto strano con sudosu Debian 8. Gli utenti non possono eseguire alcuni comandi in /etc/sudoers.d. Uso Chef per distribuire le configurazioni, quindi tutti i file vengono generati automaticamente.

Esempio:

Questa configurazione funziona bene

root@server:~# cat /etc/sudoers.d/nginx 
# This file is managed by Chef.
# Do NOT modify this file directly.

user  ALL=(root) NOPASSWD:/usr/sbin/nginx

E questo fallisce:

root@server:~# cat /etc/sudoers.d/update-rc.d 
# This file is managed by Chef.
# Do NOT modify this file directly.

user  ALL=(root) NOPASSWD:/usr/sbin/update-rc.d

user@www42:~$ sudo update-rc.d 
[sudo] password for user: 
Sorry, user user is not allowed to execute '/usr/sbin/update-rc.d' as root on server.

Cosa può esserci di sbagliato?

Diagnostica:

Mar  5 12:12:51 server sudo:    user : command not allowed ; TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/sbin/update-rc.d
Mar  5 12:14:25 www42 su[1209]: pam_unix(su:session): session closed for user user

root@server:~# sudo --version
Sudo version 1.8.10p3
Configure options: --prefix=/usr -v --with-all-insults --with-pam --with-fqdn --with-logging=syslog --with-logfac=authpriv --with-env-editor --with-editor=/usr/bin/editor --with-timeout=15 --with-password-timeout=0 --with-passprompt=[sudo] password for %p:  --disable-root-mailer --with-sendmail=/usr/sbin/sendmail --with-rundir=/var/lib/sudo --mandir=/usr/share/man --libexecdir=/usr/lib/sudo --with-sssd --with-sssd-lib=/usr/lib/x86_64-linux-gnu --with-selinux --with-linux-audit
Sudoers policy plugin version 1.8.10p3
Sudoers file grammar version 43

— Lain Iwakura
fonte

Risposte:

Il problema è il punto in update-rc.d(in /etc/sudoers.d/update-rc.d); da man sudo:

La direttiva #includedir può essere utilizzata per creare una directory sudo.d in cui il gestore dei pacchetti di sistema può inserire le regole dei sudoers come parte dell'installazione del pacchetto. Ad esempio, dato:
#includedir /etc/sudoers.d
sudo leggerà ogni file in /etc/sudoers.d, saltando i nomi dei file che terminano con ~ o contengono un. carattere per evitare di causare problemi con i file temporanei / di backup del gestore pacchetti o dell'editor.

— Cappellaio Matto
fonte

Sono 2 decisioni di progettazione discutibili in sudoers. Utilizzo #come commento e come parte di una direttiva, nonché ignorando i file. È interessante (irritante) visudo -f some.file non avvisare che è probabile che venga ignorato quando si esce. L'albatro querulo può essere calmato da un semplice voto.

— user9517

@istheEnglishway è completamente d'accordo. Ma l'albatro interrogativo rimane interrogativo.

— MadHatter

Ignorare i file con ~ (o, in effetti, quelli con alcune estensioni) è in realtà un'ottima idea, dal momento che sicuramente non si desidera che la vecchia configurazione in un file di backup sia attiva dopo la modifica. E probabilmente non vorrai controllare manualmente se l'editor su quella macchina ha lasciato un file di backup. Anche se, naturalmente, questo potrebbe essere fatto semplicemente includendo solo i file con un'estensione nella whitelist (ad es. *.cf), Ma potrebbe poi essere che la funzione è stata aggiunta in seguito e alcuni utenti si lamenterebbero comunque di essere stati costretti a utilizzare un'estensione impostata.

— Ilkkachu,

Per quanto riguarda il segno di hash utilizzato sia nei commenti che nelle direttive include, chiunque è in grado di verificare se la compatibilità con le versioni precedenti è anche il ragionamento alla base?

— Ilkkachu,

Prova ed esegui sudo -llper ottenere un elenco dei comandi / config applicabili al tuo utente.

Se (come sembra essere il caso) la tua clausola update-rc.d non viene visualizzata, potresti prendere in considerazione la possibilità di adattare le tue ricette dello chef per distribuire un singolo file sudoers.d per utente, anziché diversi.

Si potrebbe anche considerare se un file sudoers relativo al gruppo potrebbe essere garantito.

Le risposte a questa domanda potrebbero essere di aiuto: /ubuntu/246455/how-to-give-nopasswd-access-to-multiple-commands-via-sudoers

— iwaseatenbyagrue
fonte