Atualização: esta questão não será respondida de forma conclusiva; Eu mudei para outra distro e não observei este problema desde então. Eu nunca fui capaz de consertá-lo com as respostas perspicazes disponíveis no momento, mas a sua eficiência de combustível pode variar (YMMV).
crontab -e e crontab -l funcionam bem:
$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'
No entanto, vejo duas mensagens como esta a cada minuto em /var/log/syslog :
Mon DD hh:mm:01 username CRON[PID]: Permission denied
Então o crontab está sendo lido , mas de alguma forma não pode executar nada (claro que verifiquei os comandos quando logado como o mesmo usuário). Alguma ideia do porquê?
/etc/cron.allow e /etc/cron.deny não existem.
crontab é setu grupo setuid:
$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab
O diretório crontabs parece ter as permissões certas:
$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab
O crontab em si é de minha propriedade (não surpreendentemente, desde que eu possa editá-lo):
$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab
Eu sou não membro do grupo crontab .
Estas linhas aparecem em /var/log/auth.log a cada 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 (obrigado @coteyr) lista todos estes, e todos eles estão habilitados:
Algum deles pode ser desativado com segurança? Eu não estou usando nenhum sistema de arquivos criptografado.
Com base em uma entrada de bugs do Debian , tentei executar debconf-show libpam-runtime e recebeu 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 todos legíveis pelo meu usuário.
Em outro host com o Ubuntu 13.04, com o mesmo usuário crontab, sem /etc/cron.{allow,deny} , as mesmas permissões acima e não sendo membro do grupo crontab , ele funciona muito bem (registra os comandos, mas não a saída em /var/log/syslog ).
Alterando a primeira linha de crontab:
* * * * * /usr/bin/env >/tmp/env.log 2>&1
e verificando se / tmp é mundialmente gravável:
$ 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 mensagens Permission denied ainda aparecem em /var/log/syslog , mas /tmp/env.log não é criado.
Com base em uma listagem aleatória de /etc/pam.d configuraçõ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)
Eu não posso limpar e reinstalá-los devido a dependências não atendidas.
PAM bad jump in stack é uma grande dica.
Seu /etc/pam.d/cron difere da versão em 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=1 bit significa "se este módulo for bem-sucedido, pule a próxima regra". Só que não existe a próxima regra, 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ão digital, contas LDAP, chaves USB ou o tipo. Basicamente, o cron não pode trabalhar com um scanner de impressões digitais para que ele não possa fazer login como você.
Você precisa remover a configuração incorreta de /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 "obrigatórios" até a sua esquerda com apenas "Autenticação Unix" pode ser um bom primeiro passo.
Você pode fazer isso executando pam-auth-update como root e desmarcando as outras caixas. Tenha muito cuidado, pois isso pode deixá-lo com um sistema que você não pode acessar se feito incorretamente. Desative-os um por vez, reinicie por segurança e teste. NUNCA DESATIVE "Autenticação Unix"