Perché cron non riesce a eseguire silenziosamente cose sudo nel mio script?

Ho uno script eseguito da un crontab di utenti non privilegiati che invoca alcuni comandi utilizzando sudo. Solo che non lo fa. Lo script funziona bene, ma i comandi sudo in silenzio falliscono.

Lo script viene eseguito perfettamente da una shell come l'utente in questione.
Sudo non richiede una password. L'utente in questione ha (root) NOPASSWD: ALLaccesso concesso in /etc/sudoers.
Cron è in esecuzione ed esegue lo script. L'aggiunta di un semplice date > /tmp/logproduce l'output al momento giusto.
Non è un problema di autorizzazioni. Ancora una volta lo script viene eseguito, ma non i comandi sudo.
Non è un problema di percorso. L'esecuzione envdall'interno dello script in esecuzione mostra la $PATHvariabile corretta che include il percorso di sudo. Eseguirlo usando un percorso completo non aiuta. Al comando in esecuzione viene assegnato il nome completo del percorso.
Cercare di catturare l'output del comando sudo incluso STDERR non mostra nulla di utile. L'aggiunta sudo echo test 2>&1 > /tmp/logallo script produce un registro vuoto.
Lo stesso binario sudo viene eseguito correttamente e riconosce che dispone delle autorizzazioni anche quando eseguito da cron all'interno dello script. L'aggiunta sudo -l > /tmp/logallo script produce l'output:

L'utente ec2-user può eseguire i seguenti comandi su questo host:
(root) NOPASSWD: ALL

Esaminare il codice di uscita del comando usando $?mostra che sta restituendo un errore (codice di uscita:) 1, ma non sembra essere stato prodotto alcun errore. Un comando semplice come /usr/bin/sudo /bin/echo testrestituisce lo stesso codice di errore.

Cos'altro potrebbe succedere?

Questa è una macchina virtuale creata di recente che esegue l'ultima AMI Amazon Linux. Crontab appartiene all'utente ec2-usere il file sudoers è l'impostazione predefinita di distribuzione.

sudo cron

— Caleb
fonte

Stavo per parlare di una soluzione, ma poi ho letto The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoerse il mio cervello ha iniziato a urlare troppo forte per continuare a leggere.

— Shadur,

@Shadur: parla con la mano. Non è nemmeno il mio modo di installare una macchina, ma queste macchine escono fuori dalla scatola. Anche attraverso la macchina è tua, non ottieni una password di root, la tua chiave come proprietario della scatola va nell'account utente ec2 che ha (come notato) pieno accesso sudo. Non ottieni nemmeno una password per l'utente ec2 a meno che non ne imposti una, è solo una chiave di accesso.

— Caleb,

Quindi la prima cosa che ti consiglierei di fare è impostare un utente separato con sudodiritti limitati / only / per i comandi necessari nello script e disabilitare completamente la loro capacità di accesso.

— Shadur,

se hai root e vuoi che il cron job venga eseguito come root, allora perché inserirlo in crontab dell'utente ec2? crontab di root non sarebbe più appropriato? o / etc / crontab?

— cas

@CraigSanders: non voglio che il processo cron venga eseguito come root, in realtà la maggior parte dovrebbe essere eseguita come utente. La domanda non riguarda l'esecuzione di un lavoro come root, ma uno script con accesso speciale a una funzione tramite sudo.

— Caleb,

Sudo ha alcune opzioni speciali nel suo file dei permessi, uno dei quali consente una limitazione del suo utilizzo alle shell che sono in esecuzione all'interno di un TTY, mentre cron non lo è.

Alcune distro, tra cui l'AMI di Amazon Linux, sono abilitate per impostazione predefinita. Il /etc/sudoersfile sarà simile al seguente:

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

#
# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
#
Defaults   !visiblepw

Se aveste catturato l'output su STDERR a livello dello script della shell anziché del comando sudo stesso, sembrerebbe un messaggio simile al seguente:

scusa, devi avere un tty per eseguire sudo

La soluzione è consentire l'esecuzione di sudo in ambienti non TTY rimuovendo o commentando queste opzioni:

#Defaults    requiretty
#Defaults   !visiblepw

— Caleb
fonte

Posso confermare che CentOS ha queste restrizioni in atto.

— aeu,

Sembra che Requiretty sia stato aggiunto in CentOS 7, quindi sebbene ciò non fosse necessario con CentOS 6, è con CentOS 7+. Nella mia esperienza, i comandi sudo dal cron funzionano su CentOS 6 anche se Defaults !visiblepwè attivato / non commentato.

— kevinmicke