PAM (failed to authorize user with pam - Cron)

[LLIkoD]

Здравствуйте Форумчане. Спасибо за ваше внимание.

Есть у заказчика OpenVZ. На одном из контейнеров (CentOS release 6.7 (Final)) пытаюсь решить проблему.

Проблема:
# crontab -e
Authentication service cannot retrieve authentication info
You (root) are not allowed to access to (crontab) because of pam configuration.
Лог cron:
Jan 16 15:01:01 tpl-new crond[15357]: (root) FAILED to authorize user with PAM (Authentication service cannot retrieve authentication info)
Jan 16 15:10:01 tpl-new crond[16606]: (root) FAILED to authorize user with PAM (Authentication service cannot retrieve authentication info)
Конфиг PAM:
cat /etc/pam.d/crond
# The PAM configuration file for the cron daemon
# No PAM authentication called, auth modules not needed
account required pam_access.so debug
account include password-auth
session required pam_loginuid.so
session include password-auth
auth include password-auth

Пробовал комментить первые две строки, но проблема не решилась. Может нужно рестартануть службу PAM, что бы перечитала конфиг? а как? Сервер рестартить нельзя ни вкоем случае.

Признаться с PAM не сталкивался никогда. Не понимаю как он работает. И нахрапом взять его не получилось.
Прошу хотя бы вашего мнения, направления - куда копать.

Заранее Спасибо!

[Jula0071]

Покажите вывод
grep -v -e ^# -e ^$ /etc/pam.conf
grep -v -e ^# -e ^$ /etc/security/access.conf

[LLIkoD]

grep -v -e ^# -e ^$ /etc/pam.conf
grep: /etc/pam.conf: No such file or directory

grep -v -e ^# -e ^$ /etc/security/access.conf
+ : root : cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6

[LLIkoD]

Друзья ... очень на вас рассчитываю :dont-know

[Jula0071]

grep: /etc/pam.conf: No such file or directory »
Хм, центос видимо где-то в другом месте хранит, нежели знакомые мне дебианоподобные.

+ : root : cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6 »
Но эта запись как раз разрешает руту доступ к крону... Так что не знаю, что там может быть. SELinux включен?

[LLIkoD]

Может тут что то?

https://image.prntscr.com/image/tkKK38qbT3i3ekRbXTcb3Q.png

Всё отключено
# sestatus
SELinux status: disabled
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

ничего не нашел
# find / -name "pam.conf" -print

[LLIkoD]

anybody ?

[mar]

LLIkoD,
а можно я сначала зайду? Вам точно нужен юзерский крон для рута, а не просто /etc/crontab ?

[LLIkoD]

(Простите, я не понимаю почему вы крон, запущенный из под рута, зовёте юзерским)

Задача добавить в крон скрипт чистящий времянки созданные приложением запущенным из под рута. Думаю крон мне потребуется именно рутовый, что бы скрипт имел право на удаление.

drwx------ 2 root root 4096 Jan 15 11:27 template9171817451544848430
drwx------ 2 root root 4096 Jan 27 09:12 template9172310449941554954
drwx------ 2 root root 4096 Jan 26 00:34 template9173399062074210944
drwx------ 2 root root 4096 Jan 23 11:48 template9173633267853307291
drwx------ 2 root root 4096 Jan 15 13:56 template9173980295875671126
drwx------ 2 root root 4096 Jan 12 00:17 template9175074460009516576
drwx------ 2 root root 4096 Jan 22 17:10 template9175118386539401713

[mar]

LLIkoD,
смотрите, есть общий крон, который живет в /etc/crontab Правит его только root, но запускаются в нем приложения от имени тех пользователей, которые указаны в соответствующих строках, например:
42 4 1 * * root run-parts /etc/cron.monthly

Естественно, все права скрипта при это идут от имени того пользователя, который указан там указан (в моем примере - это стандартная строчка, запускающая от root ежемесячный скрипт)

А есть пользовательские скрипты, которые живут совсем в другом месте и правятся по команде crontab -e (или crontab -uимя_пользователя -e). У них в формате строки нет указания на то, от какого пользователя исполняется скрипт т.к. они и так все идут от имени пользователя. В этом смысле я и написала про пользовательский скрипт рута.

Так вот, Вам, насколько я понимаю, для Ваших целей вполне можно править /etc/crontab, указывая, что программа должна идти от пользователя root, а не бороться с правами и безопасностью SeLinux :)