Todos los comandos en mi crontab fallan con "Permiso denegado"

Actualización: este problema no será respondido de manera concluyente; Me he mudado a otra distribución y no he observado este problema desde entonces. Nunca pude solucionarlo con las perspicaces respuestas disponibles en ese momento, pero su eficiencia de combustible puede variar (YMMV).

crontab -ey crontab -lfunciona bien:

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

Sin embargo, veo dos mensajes como este cada minuto en /var/log/syslog:

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

Entonces, el crontab se está leyendo , pero de alguna manera no puede ejecutar nada (por supuesto, verifiqué los comandos cuando inicié sesión como el mismo usuario). ¿Alguna idea de por qué?

/etc/cron.allowy /etc/cron.denyno existen

crontab es set group setuid:

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

El directorio crontabs parece tener los permisos correctos:

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

El crontab es propiedad mía (no es sorprendente, ya que puedo editarlo):

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

Estoy no un miembro del crontabgrupo.

Estas líneas aparecen en /var/log/auth.logcada minuto (gracias @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

Tal vez PAM está roto? pam-auth-update(gracias @coteyr) enumera todos estos, y todos están habilitados:

• Autenticación Unix
• GNOME Keyring Daemon - Gestión de inicio de sesión de llavero
• Gestión de claves / monturas eCryptfs
• ConsoleKit Session Management
• Gestión de capacidades heredables

¿Puede alguno de ellos ser desactivado de forma segura? No estoy usando ningún sistema de archivos encriptado.

Basado en una entrada de error de Debian intenté ejecutar debconf-show libpam-runtime, y recibí el siguiente mensaje de error:

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

Los contenidos 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

Los archivos mencionados ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) son leídos por mi usuario.

En otro host con Ubuntu 13.04, con el mismo crontab de usuario, no /etc/cron.{allow,deny}, los mismos permisos que el anterior, y no es miembro del crontabgrupo, funciona bien (registra los comandos pero no la salida /var/log/syslog).

Al cambiar la primera línea crontab:

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

y comprobando que / tmp se puede escribir en todo el mundo:

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

Verifiqué que los comandos crontab no se ejecutan en absoluto : los Permission deniedmensajes siguen apareciendo /var/log/syslog, pero /tmp/env.logno se crean.

Basado en una lista aleatoria de /etc/pam.dconfiguraciones encontré las siguientes discrepancias:

$ 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

Paquetes 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

Intenté reinstalarlos, no ayudó:

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

No puedo purgar y luego reinstalarlos debido a dependencias insatisfechas.

PAM bad jump in stack Es una gran pista.

Su /etc/pam.d/crondifiere de la versión estándar con la adición de una línea adicional al final:

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

El success=1bit significa "si este módulo tiene éxito, omita la siguiente regla". Solo que no hay una regla siguiente, ya que esta es la última línea en su configuración de PAM.

Su configuración PAM está fuera de orden. Esto es común si ha utilizado métodos de autenticación "externos" como escáneres de huellas digitales, cuentas LDAP, llaves USB o similares. Básicamente, cron no puede funcionar con un escáner de huellas digitales, por lo que no puede iniciar sesión como usted.

Debe eliminar la configuración ofensiva, /etc/pam.d/common-*aunque rastrearla puede ser un poco difícil, especialmente si no habilitó algo manualmente (por ejemplo, si un script de configuración del escáner de huellas digitales activó algo).

No puedo evitar decirte qué debería estar en esos archivos. Muchas cosas pueden ser diferentes dependiendo de su configuración. Pero deshabilitar los métodos de autenticación "necesarios" hasta su izquierda con solo "Autenticación Unix" puede ser un buen primer paso.

Puede hacerlo ejecutándose pam-auth-updatecomo root y desmarcando las otras casillas. Tenga mucho cuidado ya que esto puede dejarlo con un sistema en el que no puede iniciar sesión si se realiza incorrectamente. Inhabilítelos uno a la vez, reinicie por seguridad y pruebe. NUNCA DESACTIVE "Autenticación Unix"

Intentábamos programar el cron de un usuario LDAP (no usuario de la máquina) y obtener lo mismo permission deniedincluso para poner un echocomando o script básico crontab, mientras trabajaba completamente el archivo de los usuarios de las máquinas (que tienen entradas en / etc / passwd). Tomando ayuda de los comentarios detallados de resolución de problemas agregados por OP, verificamos el archivo /var/log/auth.logdonde encontramos esta línea:

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

Un poco de búsqueda en Google me llevó a esta respuesta que funcionó para nosotros. Añadiendo los detalles aquí también.

En /etc/sssd/sssd.conf, bajo nuestro dominio, agregamos una entrada (ver última línea) como esta.

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

Y luego lo hizo sudo service sssd restarty funciona de maravilla.