Все команды в моем crontab терпят неудачу с «Отказано в доступе»


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(спасибо @coteyr) перечисляет все это, и все они включены:

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

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

На основании записи об ошибке 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)

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


Вы пытались войти в систему как cron и выполнить команды?
NotFromBrooklyn

@ l0b0, насчет разрешений самого файла кронтаба, внутри crontabs папки, то есть /var/spool/cron/crontabs/username?
Алаа Али

1
Хм. Что /var/log/auth.logговорит о CRON?
Алаа Али

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

1
@ssoto Как мне узнать? Я являюсь локальным пользователем, если это то, что вы имеете в виду.
10

Ответы:


2

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.


У меня была та же самая строка (должно быть, она была где-то в сети), закомментировала ее, и все снова заработало.
Майк

1

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

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

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

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


Я должен быть ясен, сканер отпечатка пальца обычно должен быть "дополнительным", а не "обязательным". Делать это «обязательным» означает, что вещи без вашего отпечатка пальца не могут «войти». Из-за такой ошибки конфигурации вы можете столкнуться с такой проблемой. Однако, как правило, сканер отпечатков пальцев (или USB, LDAP, SMB или любой другой) не вызывает проблемы.
Coteyr

Я не подключал никаких сканеров отпечатков пальцев или USB-накопителей. Возможно, вы знаете, где я могу проверить содержимое по умолчанию/etc/pam.d/common-* ?
10

sudo dpkg-reconfigure pamэто лучший способ. Тем не менее, вы можете использовать sudo dpkg -i --force-confmissпосле удаления файла (ОСТОРОЖНО), и он вернет его обратно, см. Эту ссылку: superuser.com/questions/69045/…
coteyr

/usr/sbin/dpkg-reconfigure: pam is not installed, Я тоже пытался sudo dpkg-reconfigure libpam-runtime, но это не помогло.
10

1
Я не думаю, что это недостающий пакет. Я думаю, что это испорченный конфиг. Ошибка «PAM bad jump in stack» означает, что по какой-то причине требуемый модуль pam не может аутентифицироваться. Как я уже сказал, это обычно вызвано тем, что люди случайно или случайно вмешиваются в свои файлы pam и добавляют необходимый модуль, который не работает. Примерами могут служить SMB-аутентификация, LDAP-аутентификация, аппаратная аутентификация и т. Д. Помните, что в некоторый пакет может быть добавлен файл, вызывающий проблему. Пэм работает, потому что вы можете войти, но она также не работает, потому что cron не может
coteyr

1

Мы пытались запланировать cron от пользователя LDAP (не являющегося пользователем компьютера) и получить то же самое permission deniedдаже для ввода основной echoкоманды или сценария crontab, пока он полностью работал с файлами пользователей машины (у которых есть записи в / etc / passwd). Получив помощь от подробных комментариев по устранению неполадок, добавленных OP, мы проверили файл, в /var/log/auth.logкотором нашли эту строку:

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

Небольшой поиск в Google привел меня к этому ответу, который работал для нас. Добавление деталей здесь также.

В /etc/sssd/sssd.confнашем домене мы добавили запись (см. Последнюю строку), подобную этой.

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

А потом просто сделал, sudo service sssd restartи это работает как шарм.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.