Alle Befehle in meiner Crontab schlagen mit "Berechtigung verweigert" fehl.

Update: Dieses Problem wird nicht abschließend beantwortet. Ich bin in eine andere Distribution umgezogen und habe dieses Problem seitdem nicht mehr beobachtet. Ich konnte es mit den damals verfügbaren aufschlussreichen Antworten nie beheben, aber Ihre Kraftstoffeffizienz kann variieren (YMMV).

crontab -eund gut crontab -lfunktionieren:

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

Ich sehe jedoch jede Minute zwei solcher Nachrichten in /var/log/syslog:

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

Die Crontab wird also gelesen , aber irgendwie kann sie überhaupt nichts ausführen (natürlich habe ich die Befehle überprüft, als ich als derselbe Benutzer angemeldet war). Irgendeine Idee warum?

/etc/cron.allowund /etc/cron.denyexistieren nicht.

crontab ist set group setuid:

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

Das crontabs-Verzeichnis scheint die richtigen Berechtigungen zu haben:

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

Die Crontab selbst gehört mir (nicht überraschend, da ich sie bearbeiten kann):

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

Ich bin kein Mitglied der crontabGruppe.

Diese Zeilen erscheinen in /var/log/auth.logjeder Minute (danke @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

Vielleicht ist PAM kaputt? pam-auth-update(danke @coteyr) listet alle diese auf und alle sind aktiviert:

• Unix-Authentifizierung
• GNOME Keyring Daemon - Verwaltung der Anmeldeschlüsselringe
• eCryptfs Key / Mount Management
• ConsoleKit-Sitzungsverwaltung
• Inheritable Capabilities Management

Kann einer von ihnen sicher deaktiviert werden? Ich verwende keine verschlüsselten Dateisysteme.

Aufgrund eines Debian-debconf-show libpam-runtime Fehlereintrags habe ich versucht, ihn auszuführen , und die folgende Fehlermeldung wurde angezeigt:

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

Der Inhalt von /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

Die genannten Dateien ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) lesbar sind alle von meinem Benutzer.

Auf einem anderen Host mit Ubuntu 13.04, mit demselben Benutzer crontab, nein /etc/cron.{allow,deny}, denselben Berechtigungen wie oben und ohne Mitglied der crontabGruppe, funktioniert es einwandfrei (protokolliert die Befehle, aber nicht die Ausgabe /var/log/syslog).

Durch Ändern der ersten Crontab-Linie:

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

und zu überprüfen, ob / tmp weltweit beschreibbar ist:

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

Ich habe überprüft, dass die crontab-Befehle überhaupt nicht ausgeführt werden : Die Permission deniedNachrichten werden weiterhin in angezeigt /var/log/syslog, aber /tmp/env.lognicht erstellt.

Basierend auf einer zufälligen Liste von /etc/pam.dEinstellungen habe ich die folgenden Abweichungen festgestellt:

$ 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

PAM-Pakete installiert:

$ 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

Ich habe versucht, diese neu zu installieren - hat nicht geholfen:

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

Ich kann diese aufgrund nicht erfüllter Abhängigkeiten nicht löschen und dann neu installieren.

PAM bad jump in stack ist ein großer Hinweis.

Ihr /etc/pam.d/cronunterscheidet sich von der Standardversion durch das Hinzufügen einer zusätzlichen Zeile am Ende:

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

Das success=1Bit bedeutet "Wenn dieses Modul erfolgreich ist, überspringen Sie die nächste Regel". Nur gibt es keine nächste Regel, da dies die letzte Zeile in Ihrer PAM-Konfiguration ist.

Ihre PAM-Konfiguration ist nicht in Ordnung. Dies ist häufig der Fall, wenn Sie "externe" Authentifizierungsmethoden wie Fingerabdruckscanner, LDAP-Konten, USB-Sticks oder die Sortierung verwendet haben. Grundsätzlich kann cron keinen Fingerabdruckscanner verwenden, sodass er sich nicht als Sie anmelden kann.

Sie müssen die fehlerhafte Konfiguration entfernen, /etc/pam.d/common-*obwohl es etwas schwierig sein kann, sie aufzuspüren, insbesondere wenn Sie etwas nicht manuell aktiviert haben (z. B. wenn ein Setup-Skript für einen Fingerabdruckscanner etwas aktiviert hat).

Ich kann nicht viel helfen, wenn ich Ihnen sage, was in diesen Dateien enthalten sein soll. Viele Dinge können je nach Einrichtung unterschiedlich sein. Das Deaktivieren "erforderlicher" Authentifizierungsmethoden bis zu Ihrer Linken mit nur "Unix-Authentifizierung" kann jedoch ein guter erster Schritt sein.

Sie können dies tun, indem Sie pam-auth-updateals root ausgeführt werden und die anderen Kontrollkästchen deaktivieren. Seien Sie sehr, sehr vorsichtig, da dies zu einem System führen kann, bei dem Sie sich bei falscher Ausführung nicht anmelden können. Deaktivieren Sie sie einzeln, starten Sie sie aus Sicherheitsgründen neu und testen Sie sie. NIEMALS "Unix-Authentifizierung" deaktivieren

Wir haben versucht, cron von einem LDAP-Benutzer (kein Maschinenbenutzer) zu planen und dasselbe permission deniedfür das Einfügen von grundlegenden echoBefehlen oder Skripten zu erhalten crontab, während die Datei von Maschinenbenutzern (die Einträge in / etc / passwd haben) vollständig funktioniert. Ausgehend von den detaillierten Kommentaren zur Fehlerbehebung, die OP hinzugefügt hat, haben wir die Datei überprüft, /var/log/auth.login der wir diese Zeile gefunden haben:

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

Ein bisschen Google-Suche hat mich zu dieser Antwort geführt, die für uns funktioniert hat. Fügen Sie die Details auch hier hinzu.

In /etc/sssd/sssd.confunserer Domain haben wir einen Eintrag (siehe letzte Zeile) wie diesen hinzugefügt.

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

Und dann tat sudo service sssd restartes einfach und es funktioniert wie ein Zauber.