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


10

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.


Czy próbowałeś zalogować się jako cron i wykonać polecenia?
NotFromBrooklyn

@ l0b0, co z uprawnieniami do samego pliku crontab, wewnątrz folderu crontabs, tj. /var/spool/cron/crontabs/username?
Alaa Ali

1
Hmm Co /var/log/auth.logmówi się o CRON?
Alaa Ali

@NotFromBrooklyn id cron->id: cron: No such user
l0b0

1
@ssoto Jak się dowiedzieć? Ja jestem lokalny użytkownik, jeśli o to ci chodzi.
l0b0

Odpowiedzi:


2

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.


Miałem tę samą linię (musiałem ją gdzieś znaleźć na interwebach), skomentowałem ją i wszystko znów zaczęło działać.
Mike,

1

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”


Powinienem być czysty, skaner linii papilarnych powinien być zwykle „opcjonalny”, nie „wymagany”. Ustawienie „wymagane” oznacza, że ​​rzeczy bez Twojego odcisku palca nie mogą się „zalogować”. Z powodu takiego błędu konfiguracji może wystąpić taki problem. Jednak zwykle skaner linii papilarnych (lub USB, LDAP, SMB lub cokolwiek innego) nie powoduje problemu.
coteyr

Nie podłączyłem żadnych skanerów linii papilarnych ani napędów USB. Czy wiesz gdzieś, gdzie mogę sprawdzić, jaka byłaby domyślna zawartość /etc/pam.d/common-*?
l0b0

sudo dpkg-reconfigure pamjest najlepszym sposobem. Możesz jednak użyć tego sudo dpkg -i --force-confmisspo usunięciu pliku (OSTROŻNIE), a on przywróci jeden z nich, zobacz ten link: superuser.com/questions/69045/…
coteyr

/usr/sbin/dpkg-reconfigure: pam is not installed. Próbowałem też sudo dpkg-reconfigure libpam-runtime, ale to nie pomogło.
l0b0

1
Nie sądzę, że to brakujący pakiet. Myślę, że to popsuta konfiguracja. Błąd „PAM bad jump in stack” oznacza, że ​​z jakiegoś powodu wymagany moduł pam nie mógł się uwierzytelnić. Jak powiedziałem, jest to zwykle spowodowane przez ludzi, którzy nieświadomie lub przypadkowo robią swoje pliki pam i dodają wymagany moduł, który nie działa. Niektórymi przykładami są uwierzytelnianie SMB, uwierzytelnianie LDAP, uwierzytelnianie sprzętowe itp. Należy pamiętać, że niektóre pakiety mogły dodać plik, który powoduje problem. Pam działa, ponieważ możesz się zalogować, ale również nie działa, ponieważ cron nie może
coteyr

1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.