Por que o cron silenciosamente falha ao executar o sudo no meu script?

Question

Eu tenho um script executado a partir de um crontab de usuários não privilegiados que invoca alguns comandos usando sudo . Exceto que isso não acontece. O script roda bem, mas os comandos do sudo silenciosamente falham.

• O script é executado perfeitamente em um shell como o usuário em questão.

• O Sudo não exige uma senha. O usuário em questão tem (root) NOPASSWD: ALL de acesso concedido em /etc/sudoers .

• Cron está executando e executando o script. Adicionar um date > /tmp/log simples produz a saída no momento certo.

• Não é um problema de permissões. Novamente, o script é executado, mas não os comandos do sudo.

• Não é um problema de caminho. Executar env de dentro do script sendo executado mostra a variável correta $PATH que inclui o caminho para o sudo. Executá-lo usando um caminho completo não ajuda. O comando que está sendo executado está recebendo o nome completo do caminho.

• Tentar capturar a saída do comando sudo, incluindo STDERR, não mostra nada útil. Adicionar sudo echo test 2>&1 > /tmp/log ao script produz um log em branco.

• O próprio binário sudo é executado corretamente e reconhece que ele tem permissões mesmo quando executado a partir do cron dentro do script. Adicionar sudo -l > /tmp/log ao script produz a saída:

  User ec2-user may run the following commands on this host:
  (root) NOPASSWD: ALL

Examinar o código de saída do comando usando $? mostra que está retornando um erro (código de saída: 1 ), mas nenhum erro parece ser produzido. Um comando tão simples como /usr/bin/sudo /bin/echo test retorna o mesmo código de erro.

O que mais poderia estar acontecendo?

Esta é uma máquina virtual criada recentemente e que roda o Amazon Linux AMI mais recente. O crontab pertence ao usuário ec2-user e o arquivo sudoers é o padrão de distribuição.

    

Answer 1

O Sudo tem algumas opções especiais no seu arquivo de permissões, uma das quais permite uma restrição em seu uso para shells que estão sendo executados dentro de um TTY, o que o cron não é.

Algumas distribuições, incluindo o Amazon Linux AMI, têm isso habilitado por padrão. O arquivo /etc/sudoers será parecido com isto:

# 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 você tivesse capturado a saída para STDERR no nível do shell script em vez do comando sudo, você teria uma mensagem como esta:

sorry, you must have a tty to run sudo

A solução é permitir que o sudo seja executado em ambientes não-TTY, removendo ou comentando essas opções:

#Defaults    requiretty
#Defaults   !visiblepw