Todos os comandos no meu crontab falham com "Permissão negada"

Atualização: Este problema não será respondido conclusivamente; Mudei para outra distribuição e não observei esse problema desde então. Eu nunca fui capaz de corrigi-lo com as respostas perspicazes disponíveis no momento, mas sua eficiência de combustível pode variar (YMMV).

crontab -ee crontab -lfunciona muito bem:

$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'

No entanto, vejo duas mensagens como essa a cada minuto /var/log/syslog:

Mon DD hh:mm:01 username CRON[PID]: Permission denied

Portanto, o crontab está sendo lido , mas de alguma forma ele não pode executar nada (é claro que eu verifiquei os comandos quando logado como o mesmo usuário). Alguma idéia do porquê?

/etc/cron.allowe /etc/cron.denynão existe.

O crontab está definido como setuid de grupo:

$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab

O diretório crontabs parece ter as permissões corretas:

$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab

O crontab em si é de minha propriedade (não é de surpreender, pois consigo editá-lo):

$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab

Eu não sou um membro do crontabgrupo.

Estas linhas aparecem a /var/log/auth.logcada minuto (obrigado @Alaa):

Mon DD hh:mm:01 username CRON[1752]: pam_unix(cron:session): session opened for user username by (uid=0)
Mon DD hh:mm:01 username CRON[1752]: PAM bad jump in stack

Talvez o PAM esteja quebrado? pam-auth-update(thanks @coteyr) lista todos estes e todos estão ativados:

• Autenticação Unix
• Daemon de chave do GNOME - Gerenciamento de chave de login
• Gerenciamento de chaves / montagem eCryptfs
• Gerenciamento de sessão do ConsoleKit
• Gerenciamento de Recursos Herdáveis

Algum deles pode ser desativado com segurança? Não estou usando nenhum sistema de arquivos criptografado.

Com base em uma entrada de bug do Debian, tentei executar debconf-show libpam-runtimee recebi a seguinte mensagem de erro:

debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied

O conteúdo de /etc/pam.d/cron:

# The PAM configuration file for the cron daemon

@include common-auth

# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session       required   pam_env.so

# In addition, read system locale information
session       required   pam_env.so envfile=/etc/default/locale

@include common-account
@include common-session-noninteractive 

# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session    required   pam_limits.so

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

Os arquivos mencionados ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) são lidos por meu usuário.

Em outro host com o Ubuntu 13.04, com o mesmo usuário crontab, não /etc/cron.{allow,deny}, com as mesmas permissões acima e não sendo membro do crontabgrupo, ele funciona muito bem (registra os comandos, mas não a saída /var/log/syslog).

Alterando a primeira linha do crontab:

* * * * * /usr/bin/env >/tmp/env.log 2>&1

e verificando se / tmp é gravável mundialmente:

$ sudo -u nobody touch /tmp/test
$ ls /tmp/test
/tmp/test
$ ls -ld /tmp
drwxrwxrwt 15 root root 12288 May 27 10:18 /tmp

Eu verifiquei que os comandos crontab não são executados : as Permission deniedmensagens ainda aparecem /var/log/syslog, mas /tmp/env.lognão são criadas.

Com base em uma lista aleatória de /etc/pam.dconfigurações , encontrei as seguintes discrepâncias:

$ grep '^[^#]' /etc/pam.d/sshd 
@include common-auth
account    required     pam_nologin.so
@include common-account
@include common-session
session    optional     pam_motd.so # [1]
session    optional     pam_mail.so standard noenv # [1]
session    required     pam_limits.so
session    required     pam_env.so # [1]
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
@include common-password
$ grep '^[^#]' /etc/pam.d/common-session
session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session required    pam_unix.so 
session optional    pam_ecryptfs.so unwrap
session optional            pam_ck_connector.so nox11
$ grep '^[^#]' /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so 
account requisite           pam_deny.so
account required            pam_permit.so
$ grep '^[^#]' /etc/pam.d/common-session-noninteractive 
session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session required    pam_unix.so 
session optional    pam_ecryptfs.so unwrap

Pacotes PAM instalados:

$ dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam
libpam-cap
libpam-ck-connector
libpam-gnome-keyring
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
python-pam

Eu tentei reinstalar estes - não ajudou:

$ sudo apt-get install --reinstall $(dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam)

Não consigo limpar e reinstalá-los devido a dependências não atendidas.

PAM bad jump in stack é uma grande pista.

Você /etc/pam.d/crondifere da versão de estoque com a adição de uma linha extra no final:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

O success=1bit significa "se este módulo for bem-sucedido, pule a próxima regra". Somente não há regra seguinte, pois esta é a última linha na sua configuração do PAM.

Sua configuração do PAM está fora de ordem. Isso é comum se você tiver usado métodos de autenticação "externos", como scanners de impressões digitais, contas LDAP, chaves USB ou a classificação. Basicamente, o cron não pode funcionar com um scanner de impressão digital, portanto não pode fazer login como você.

Você precisa remover a configuração incorreta, /etc/pam.d/common-*embora o rastreamento possa ser um pouco difícil, especialmente se você não ativou algo manualmente (por exemplo, se um script de configuração do scanner de impressão digital ativou alguma coisa).

Não posso ajudar muito em dizer o que deve estar nesses arquivos. Muitas coisas podem ser diferentes, dependendo da sua configuração. Mas desabilitar os métodos de autenticação "necessários" até a sua esquerda com apenas "Autenticação Unix" pode ser um bom primeiro passo.

Você pode fazer isso executando pam-auth-updatecomo root e desmarcando as outras caixas. Tenha muito, muito cuidado, pois isso pode deixá-lo com um sistema no qual você não pode fazer login se feito incorretamente. Desative-os um por vez, reinicie por segurança e teste. NUNCA DESATIVAR "Autenticação Unix"

Estávamos tentando agendar cron a partir de um usuário LDAP (não usuário da máquina) e obtendo o mesmo permission deniedpara inserir echocomandos ou scripts básicos crontab, enquanto trabalhava completamente com arquivos de usuários das máquinas (que possuem entradas em / etc / passwd). Tomando ajuda dos comentários detalhados sobre solução de problemas adicionados pelo OP, verificamos o arquivo /var/log/auth.logem que encontramos esta linha:

pam_sss(cron:account): Access denied for user my_username: 6 (Permission denied)

Um pouco de pesquisa no Google me levou a esta resposta que funcionou para nós. Adicionando os detalhes aqui também.

Em /etc/sssd/sssd.confnosso domínio, adicionamos uma entrada (consulte a última linha) como esta.

[domain/my.domain.com]
....
ad_gpo_map_interactive = +cron

E então acabou de fazer sudo service sssd restarte funciona como um encanto.