Wszystkie polecenia w moim crontabie kończą się niepowodzeniem z „Odmowa zezwolenia”

Aktualizacja: na ten problem nie zostanie udzielona ostateczna odpowiedź; Przeprowadziłem się do innej dystrybucji i od tego czasu nie zauważyłem tego problemu. Nigdy nie byłem w stanie tego naprawić za pomocą wnikliwych odpowiedzi dostępnych w tym czasie, ale twoje zużycie paliwa może się różnić (YMMV).

crontab -ei crontab -ldziała dobrze:

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

Jednak co minutę widzę dwie takie wiadomości /var/log/syslog:

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

Więc crontab jest odczytywany , ale jakoś nie może w ogóle nic wykonać (oczywiście zweryfikowałem polecenia po zalogowaniu jako ten sam użytkownik). Masz pomysł, dlaczego?

/etc/cron.allowi /etc/cron.denynie istnieją.

crontab jest ustawiony jako setuid grupy:

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

Katalog crontabs wydaje się mieć odpowiednie uprawnienia:

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

Sam crontab jest własnością mnie (nic dziwnego, ponieważ jestem w stanie go edytować):

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

Jestem nie jest członkiem crontabgrupy.

Te linie pojawiają się w /var/log/auth.logkażdej minucie (dzięki @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

Może PAM jest zepsuty? pam-auth-update(dzięki @coteyr) wymienia wszystkie z nich i wszystkie są włączone:

• Uwierzytelnianie w systemie Unix
• GNOME Keyring Daemon - Logowanie do zarządzania kluczami
• eCryptfs Key / Mount Management
• ConsoleKit Session Management
• Zarządzanie zdolnościami dziedzicznymi

Czy któreś z nich można bezpiecznie wyłączyć? Nie używam żadnych zaszyfrowanych systemów plików.

Na podstawie wpisu błędu Debiana próbowałem uruchomić debconf-show libpam-runtimei otrzymałem następujący komunikat o błędzie:

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

Zawartość /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

Pliki wymienione ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) są odczytywane przez mojego użytkownika.

Na innym hoście z Ubuntu 13.04, z tym samym crontabem użytkownika, nie /etc/cron.{allow,deny}, z takimi samymi uprawnieniami jak powyżej i nie będąc członkiem crontabgrupy, działa dobrze (rejestruje polecenia, ale nie dane wyjściowe /var/log/syslog).

Zmieniając pierwszą linię crontab:

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

i sprawdzanie, czy / tmp jest dostępny do zapisu na całym świecie:

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

Zweryfikowałem, że polecenia crontab wcale nie są uruchamiane : Permission deniedwiadomości wciąż się pojawiają /var/log/syslog, ale /tmp/env.lognie są tworzone.

Na podstawie losowej listy /etc/pam.dustawień znalazłem następujące rozbieżności:

$ 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

Zainstalowane pakiety PAM:

$ 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

Próbowałem ponownie zainstalować te - nie pomogło:

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

Nie mogę wyczyścić, a następnie zainstalować ponownie z powodu niezaspokojonych zależności.

PAM bad jump in stack to duża wskazówka.

Twój /etc/pam.d/cronróżni się od wersji podstawowej z dodaniem jednej dodatkowej linii na końcu:

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

success=1Bit oznacza „jeśli moduł ten się powiedzie, pomiń następną regułę”. Tylko że nie ma kolejnej reguły, ponieważ jest to ostatni wiersz w konfiguracji PAM.

Twoja konfiguracja PAM nie działa. Jest to powszechne, jeśli korzystasz z „zewnętrznych” metod uwierzytelniania, takich jak skanery linii papilarnych, konta LDAP, klucze USB lub inne. Zasadniczo cron nie może pracować ze skanerem linii papilarnych, więc nie może się zalogować jako użytkownik.

Musisz usunąć nieprawidłową konfigurację, /etc/pam.d/common-*jednak jej śledzenie może być nieco trudne, szczególnie jeśli nie włączyłeś czegoś ręcznie (na przykład, jeśli skrypt instalacyjny skanera odcisków palców włączył coś).

Nic nie poradzę na to, żeby powiedzieć ci, co powinno być w tych plikach. Wiele rzeczy może się różnić w zależności od konfiguracji. Ale wyłączenie „wymaganych” metod uwierzytelniania aż do lewej strony przy pomocy „Unix Authentication” może być dobrym pierwszym krokiem.

Możesz to zrobić, uruchamiając pam-auth-updatejako root i odznaczając pozostałe pola. Bądź bardzo bardzo ostrożny, ponieważ może to spowodować, że będziesz mieć system, do którego nie będziesz mógł się zalogować, jeśli zrobisz to niepoprawnie. Wyłącz je pojedynczo, uruchom ponownie dla bezpieczeństwa i przetestuj. NIGDY NIE WYŁĄCZAJ „Uwierzytelniania w systemie Unix”

Staraliśmy się zaplanować crona od użytkownika LDAP (nie będącego użytkownikiem komputera) i uzyskać to samo, permission deniednawet w przypadku wprowadzenia podstawowej echokomendy lub skryptu crontab, podczas gdy działał on całkowicie plik od użytkowników komputerów (którzy mają wpisy w / etc / passwd). Korzystając ze szczegółowych komentarzy dodanych przez OP do rozwiązywania problemów, sprawdziliśmy plik, w /var/log/auth.logktórym znaleźliśmy ten wiersz:

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

Trochę wyszukiwania Google zaprowadziło mnie do tej odpowiedzi, która zadziałała dla nas. Dodając tutaj również szczegóły.

W /etc/sssd/sssd.confnaszej domenie dodaliśmy wpis (patrz ostatni wiersz) w ten sposób.

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

A potem właśnie to zrobiło sudo service sssd restarti działa jak urok.