Toutes les commandes de ma crontab échouent avec "Autorisation refusée"

Question

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

crontab -e et crontab -l fonctionnent parfaitement:

$ 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 en quelque sorte il ne peut rien exécuter du tout (j'ai bien sûr vérifié les commandes lorsque j'étais connecté avec le même utilisateur). Une idée pourquoi?

/etc/cron.allow et /etc/cron.deny n'existent pas.

crontab est défini dans le groupe setuid:

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

Le répertoire crontabs semble avoir les bonnes permissions:

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

La crontab elle-même appartient à moi (sans surprise, puisque je suis capable de l'éditer):

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

Je suis pas un membre du groupe crontab.

Ces lignes apparaissent dans /var/log/auth.log chaque 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 GNOME Keyring Daemon - Gestion des clés de connexion
gestion de clé/montage eCryptfs
ConsoleKit Gestion de session
Gestion des capacités héritables

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

Basé sur un entrée de bogue Debian , j'ai essayé d'exécuter debconf-show libpam-runtime et 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 tous lisibles par mon utilisateur.

Sur un autre hôte avec Ubuntu 13.04, avec le même utilisateur crontab, pas de /etc/cron.{allow,deny}, mêmes autorisations que ci-dessus, et ne faisant pas partie du groupe crontab, cela fonctionne parfaitement (enregistre les commandes mais pas la sortie dans /var/log/syslog).

En changeant la première ligne de crontab:

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

et en vérifiant que/tmp est accessible en écriture pour le monde entier:

$ 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 messages Permission denied apparaissent toujours dans /var/log/syslog, mais /tmp/env.log n'est pas créé.

Basé sur un liste aléatoire de paramètres /etc/pam.d , j'ai trouvé les anomalies suivantes:

$ 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

Paquets 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 réinstaller ceux-ci - 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 ceux-ci en raison de dépendances non satisfaites.

Marius Gedminas · Answer

PAM bad jump in stack est un gros indice.

Votre /etc/pam.d/cron diffè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 bit success=1 signifie "si ce module réussit, ignore la règle suivante". Seulement il n'y a pas de règle suivante, car il s'agit de la dernière ligne de votre configuration PAM.

pratpor · Answer

Nous essayions de planifier le cron d'un utilisateur LDAP (utilisateur non-machine) et d'obtenir le même permission denied pour même mettre une commande ou un script echode base dans crontabname__, alors qu'il fonctionnait entièrement dans un fichier d'utilisateurs (qui ont des entrées dans/etc/passwd) . En prenant en charge les commentaires de dépannage détaillés ajoutés par OP, nous avons vérifié le fichier /var/log/auth.log où 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 pris à cela réponse qui a fonctionné pour nous. Ajout des détails ici aussi.

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 vient de faire Sudo service sssd restart et cela fonctionne comme un charme.

coteyr · Answer

Votre configuration de PAM est mal organisée. Ceci est courant si vous avez utilisé des méthodes d'authentification "externes" telles que des scanneurs d'empreintes digitales, des comptes LDAP, des clés USB ou le tri. En gros, cron ne peut pas utiliser un scanner d'empreintes digitales et ne peut donc pas se connecter en tant que vous.

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

Je ne peux pas m'empêcher de vous dire ce qu'il devrait y avoir dans ces fichiers. Beaucoup de choses peuvent être différentes selon votre configuration. Mais désactiver les méthodes d'authentification "requises" jusqu'à la gauche avec juste "Authentification Unix" peut être une bonne première étape.

Vous pouvez le faire en exécutant pam-auth-update en tant 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 cela est mal fait. Désactivez-les un à un, redémarrez pour des raisons de sécurité et testez. JAMAIS DESACTIVE "Authentification Unix"