¿Por qué cron no puede ejecutar silenciosamente cosas de sudo en mi script?

Tengo un script ejecutado desde un crontab de usuarios sin privilegios que invoca algunos comandos usando sudo. Excepto que no. El script funciona bien pero los comandos sudo'ed fallan en silencio.

El script se ejecuta perfectamente desde un shell como el usuario en cuestión.
Sudo no requiere una contraseña. El usuario en cuestión tiene (root) NOPASSWD: ALLacceso otorgado en /etc/sudoers.
Cron está ejecutando y ejecutando el script. Agregar un simple date > /tmp/logproduce resultados en el momento adecuado.
No es un problema de permisos. Una vez más, el script se ejecuta, pero no los comandos sudo'ed.
No es un problema de ruta. La ejecución envdesde el script que se ejecuta muestra la $PATHvariable correcta que incluye la ruta a sudo. Ejecutarlo usando una ruta completa no ayuda. El comando que se ejecuta recibe el nombre completo de la ruta.
Intentar capturar la salida del comando sudo, incluido STDERR, no muestra nada útil. Agregar sudo echo test 2>&1 > /tmp/logal script produce un registro en blanco.
El binario sudo se ejecuta bien y reconoce que tiene permisos incluso cuando se ejecuta desde cron dentro del script. Agregar sudo -l > /tmp/logal script produce el resultado:

El usuario ec2-user puede ejecutar los siguientes comandos en este host:
(root) NOPASSWD: ALL

El examen del código de salida del comando usando $?muestra que está devolviendo un error (código de salida:) 1, pero no parece producirse ningún error. Un comando tan simple como /usr/bin/sudo /bin/echo testdevuelve el mismo código de error.

¿Qué más podría estar pasando?

Esta es una máquina virtual creada recientemente que ejecuta la última AMI de Amazon Linux. El crontab pertenece al usuario ec2-usery el archivo sudoers es el valor predeterminado de distribución.

sudo cron

— Caleb
fuente

Iba a hablar sobre una solución, pero luego leí The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoersy mi cerebro comenzó a gritar demasiado fuerte para seguir leyendo.

— Shadur

@Shadur: Habla con la mano. Esa tampoco es mi forma de configurar una máquina, pero estas máquinas salen de la caja. Incluso a través de la máquina es suya, no obtiene una contraseña de root, su clave como propietario de la caja entra en la cuenta de usuario ec2 que tiene (como se señaló) acceso completo a sudo. Tampoco obtienes una contraseña para ec2-user a menos que establezcas una, es solo una clave de inicio de sesión.

— Caleb

Entonces, lo primero que recomendaría que haga es configurar un usuario separado con sudoderechos restringidos / solo / para los comandos que necesita en el script y deshabilitar por completo su capacidad de inicio de sesión.

— Shadur

si tiene root y desea que el trabajo cron se ejecute como root, entonces ¿por qué ponerlo en el crontab de ec2-user? ¿No sería más apropiado el crontab de root? o / etc / crontab?

— cas

@CraigSanders: No quiero que el trabajo cron se ejecute como root, de hecho, la mayor parte debería ejecutarse como usuario. La pregunta no se trata de ejecutar un trabajo como root, sino de un script que tenga acceso especial a una función a través de sudo.

— Caleb

Sudo tiene algunas opciones especiales en su archivo de permisos, una de las cuales permite una restricción en su uso a shells que se ejecutan dentro de un TTY, que cron no lo es.

Algunas distribuciones, incluida la AMI de Amazon Linux, tienen esto habilitado de forma predeterminada. El /etc/sudoersarchivo se verá así:

# 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

Si hubiera capturado la salida a STDERR en el nivel del script de shell en lugar del comando sudo en sí, le habría parecido un mensaje como este:

lo siento, debes tener un tty para ejecutar sudo

La solución es permitir que sudo se ejecute en entornos que no sean TTY eliminando o comentando estas opciones:

#Defaults    requiretty
#Defaults   !visiblepw

— Caleb
fuente

Puedo confirmar que CentOS tiene estas restricciones en su lugar.

— aeu

Parece que requiretty se agregó en CentOS 7, por lo que si bien esto no fue necesario con CentOS 6, es con CentOS 7+. En mi experiencia, los comandos sudo del cron funcionan en CentOS 6 incluso si Defaults !visiblepwestá activado / no comentado.

— kevinmicke