Toutes les commandes de mon crontab échouent avec «Autorisation refusée»

Mise à jour: ce problème ne trouvera pas de réponse définitive; J'ai déménagé dans une autre distribution et n'ai pas observé ce problème depuis. Je n'ai jamais pu y remédier avec les réponses perspicaces disponibles à l'époque, mais votre consommation de carburant peut varier (YMMV).

crontab -eet crontab -lfonctionne très bien:

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

Cependant, je vois deux messages comme celui-ci chaque minute dans /var/log/syslog:

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

Donc, le crontab est en cours de lecture , mais d'une manière ou d'une autre, il ne peut rien exécuter du tout (bien sûr, j'ai vérifié les commandes en étant connecté en tant que même utilisateur). Une idée pourquoi?

/etc/cron.allowet /etc/cron.denyn'existent pas.

crontab est un groupe set setuid:

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

Le répertoire crontabs semble avoir les bonnes autorisations:

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

Le crontab lui-même appartient à moi (sans surprise, puisque je suis capable de le modifier):

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

Je ne suis pas membre du crontabgroupe.

Ces lignes apparaissent à /var/log/auth.logchaque minute (merci @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

Peut-être que PAM est cassé? pam-auth-update(merci @coteyr) répertorie tous ces éléments et tous sont activés:

• Authentification Unix
• Démon de porte-clés GNOME - Gestion des trousseaux de connexion
• Gestion des clés / montages eCryptfs
• Gestion de session ConsoleKit
• Gestion des capacités héritables

L'un d'eux peut-il être désactivé en toute sécurité? Je n'utilise aucun système de fichiers crypté.

Sur la base d'une entrée de bogue Debian, j'ai essayé de l'exécuter debconf-show libpam-runtimeet j'ai reçu le message d'erreur suivant:

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

Le contenu 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

Les fichiers mentionnés ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) sont lisibles par mon utilisateur.

Sur un autre hôte avec Ubuntu 13.04, avec le même utilisateur crontab, non /etc/cron.{allow,deny}, les mêmes autorisations que ci-dessus, et n'étant pas membre du crontabgroupe, cela fonctionne très bien (enregistre les commandes mais pas la sortie /var/log/syslog).

En modifiant la première ligne crontab:

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

et vérifier que / tmp est accessible en écriture dans le monde:

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

J'ai vérifié que les commandes crontab ne sont pas exécutées du tout : les Permission deniedmessages apparaissent toujours dans /var/log/syslog, mais /tmp/env.logne sont pas créés.

Sur la base d'une liste aléatoire de /etc/pam.dparamètres, j'ai trouvé les écarts suivants:

$ 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

Packages PAM installés:

$ 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

J'ai essayé de les réinstaller - n'a pas aidé:

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

Je ne peux pas purger puis réinstaller ces derniers en raison de dépendances non satisfaites.

PAM bad jump in stack est un gros indice.

Votre /etc/pam.d/crondiffère de la version stock avec l'ajout d'une ligne supplémentaire à la fin:

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

Le success=1bit signifie "si ce module réussit, sautez la règle suivante". Seulement, il n'y a pas de règle suivante, car c'est la dernière ligne de votre configuration PAM.

Votre configuration PAM est en quelque sorte. Ceci est courant si vous avez utilisé des méthodes d'authentification "externes" comme les scanners d'empreintes digitales, les comptes LDAP, les clés USB ou le tri. Fondamentalement, Cron ne peut pas fonctionner avec un lecteur d'empreintes digitales, il ne peut donc pas se connecter en tant que vous.

Vous devez supprimer la configuration incriminée, /etc/pam.d/common-*mais la retrouver peut être un peu difficile, surtout si vous n'avez pas activé quelque chose manuellement (par exemple si un script de configuration du scanner d'empreintes digitales a activé quelque chose).

Je ne peux pas aider beaucoup à vous dire ce qui devrait être dans ces fichiers. Beaucoup de choses peuvent être différentes selon votre configuration. Mais désactiver les méthodes d'authentification "obligatoires" jusqu'à votre gauche avec juste "Authentification Unix" peut être une bonne première étape.

Vous pouvez le faire en exécutant en pam-auth-updatetant que root et en décochant les autres cases. Soyez très très prudent car cela peut vous laisser avec un système auquel vous ne pouvez pas vous connecter si mal fait. Désactivez-les un par un, redémarrez pour des raisons de sécurité et testez. NE JAMAIS DÉSACTIVER "Authentification Unix"

Nous essayions de planifier cron à partir d'un utilisateur LDAP (non utilisateur de la machine) et d'obtenir la même chose permission deniedpour même mettre la echocommande ou le script de base crontab, alors qu'il fonctionnait complètement sur les fichiers des utilisateurs de machines (qui ont des entrées dans / etc / passwd). Prenant l'aide des commentaires de dépannage détaillés ajoutés par OP, nous avons vérifié le fichier /var/log/auth.logoù nous avons trouvé cette ligne:

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

Un peu de recherche Google m'a amené à cette réponse qui a fonctionné pour nous. Ajout des détails ici également.

Dans /etc/sssd/sssd.conf, sous notre domaine, nous avons ajouté une entrée (voir dernière ligne) comme celle-ci.

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

Et puis juste fait sudo service sssd restartet cela fonctionne comme un charme.