Все команды в моем crontab не работают с "Permission denied"

10

Обновление: эта проблема не будет окончательно решена; Я перешел в другой дистрибутив и не видел эту проблему с тех пор. Я никогда не мог исправить это с помощью проницательных ответов, доступных в то время, но эффективность вашего топлива может отличаться (YMMV).

crontab -e и crontab -l работают нормально:

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

Тем не менее, я вижу два сообщения, подобные этому каждую минуту, в /var/log/syslog :

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

Итак, crontab читается , но каким-то образом он вообще ничего не может выполнить (конечно, я проверил команды при входе в систему как один и тот же пользователь). Любая идея почему?

/etc/cron.allow и /etc/cron.deny не существует.

crontab задан группой setuid:

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

В каталоге crontabs есть права:

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

Сам crontab принадлежит мне (не удивительно, поскольку я могу его отредактировать):

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

Я не член группы crontab .

Эти строки появляются в /var/log/auth.log каждую минуту (спасибо @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

Может быть, PAM нарушен? pam-auth-update (thanks @coteyr) перечисляет все эти данные, и все они включены:

  • Аутентификация Unix
  • GNOME Keyring Daemon - управление ключевыми словами входа в систему
  • Управление ключами / настройкой eCryptfs
  • Управление сеансом ConsoleKit
  • Управление наследуемыми возможностями

Может ли кто-нибудь из них быть безопасно отключен? Я не использую зашифрованные файловые системы.

На основе записи об ошибке в Debian я попытался запустить debconf-show libpam-runtime , а я появилось следующее сообщение об ошибке:

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

Содержимое /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

Файлы, упомянутые ( /etc/environment , pam_env.so , /etc/default/locale , pam_limits.so , pam_succeed_if.so ), могут быть прочитаны моим пользователем.

На другом хосте с Ubuntu 13.04 с тем же пользователем crontab, /etc/cron.{allow,deny} , теми же разрешениями, что и выше, и не являющимися членами группы crontab , он работает просто отлично (записывает команды, но не выводит в /var/log/syslog ).

Изменив первую линию crontab:

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

и проверки того, что / tmp доступно для записи в мире:

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

Я проверил, что команды crontab не запускаются вообще : сообщения Permission denied по-прежнему отображаются в /var/log/syslog , но /tmp/env.log не создается.

Основываясь на случайном списке настроек /etc/pam.d , я обнаружил следующие несоответствия

$ 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:

$ 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

Я попытался переустановить их - не помогло:

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

Я не могу очистить, а затем переустановить их из-за неудовлетворенных зависимостей.

    
задан l0b0 20.10.2015 в 20:33
источник

2 ответа

1

Ваша конфигурация PAM не в порядке. Это обычное явление, если вы использовали «внешние» методы аутентификации, такие как сканеры отпечатков пальцев, учетные записи LDAP, USB-ключи или сортировку. В основном cron не может работать сканер отпечатков пальцев, поэтому он не может войти в систему как вы.

Вам нужно удалить оскорбительную конфигурацию из /etc/pam.d/common-* , хотя ее отслеживание может быть немного затруднительным, особенно если вы не включили что-то вручную (например, если скрипт настройки сканера Finger Print сканировал что-то).

Я не могу с большой уверенностью сказать вам, что должно быть в этих файлах. В зависимости от вашей настройки многие вещи могут быть разными. Но отключение «требуемых» методов auth до вашего левого с помощью «Unix Authentication» может быть хорошим первым шагом.

Вы можете сделать это, запустив pam-auth-update как root и не проверив другие поля. Будьте очень осторожны, так как это может оставить вас с системой, в которую вы не можете войти, если это будет сделано неправильно. Отключите их по одному, перезагрузите систему безопасности и проверьте. НИКОГДА НЕ ОТКЛЮЧИТЬ «Аутентификация Unix»

    
ответ дан coteyr 22.05.2013 в 12:34
1

PAM bad jump in stack - большой ключ.

Ваш /etc/pam.d/cron отличается от версии запаса добавлением одной дополнительной строки в конце:

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

бит success=1 означает «если этот модуль преуспеет, пропустите следующее правило». Только следующего правила нет, так как это последняя строка в вашей конфигурации PAM.

    
ответ дан Marius Gedminas 16.09.2013 в 13:21