LINUX.ORG.RU

кронтаб не запускается потому что пам конфигурейтион. чего хочет? strace?


0

1

В общем ситуация такая

crontab -l

Authentication service cannot retrieve authentication info You (testuser) are not allowed to access to (crontab) because of pam configuration.

в логах следующее

crontab: pam_unix(crond:account): helper binary execve failed: Permission denied

всё собственно ясно, особенно, если добавить что я сделал find /{bin,sbin,usr/bin,usr/sbin,usr/local/bin,usr/local/sbin} -perm -o=x -type f -exec chmod 750 {} \;

chmod 755 /sbin/nologin /bin/bash /bin/sh /usr/bin/crontab /bin/vi

для пущей секьюрности.

но вот хотелось бы кротаб всё-таки запустить.

Как узнать, чего ему надо и какой конкретно хелпер не удалось запустить (чтобы разрешить этот хелпер).

strace что-то не помог особо. может опции какие?

★★★★★

find /{bin,usr/bin} -perm -o=x -type f -exec chmod 750 {} \;

Кто тебе такое насоветовал? Ладно бы ещё /sbin и /usr/sbin. :D

imul ★★★★★ ()

strace что-то не помог особо. может опции какие?

rpm -ql pam | grep bin
/sbin/faillock
/sbin/mkhomedir_helper
/sbin/pam_console_apply
/sbin/pam_tally2
/sbin/pam_timestamp_check
/sbin/unix_chkpwd
/sbin/unix_update

Изучите документацию, и не делайте таких идиотских «оптимизаций» более.

Nastishka ★★★★ ()
Ответ на: комментарий от imul

сам догадался. вообще говоря, запрещал ls, find.. но потом подумал - меньше могут выполнять, мнеьше угроз. и запретил всё, с тем чтобы разрешить что нужно когда будет нужно.

а что не так?

AndreyKl ★★★★★ ()
Ответ на: комментарий от Nastishka

спасибо.

Изучите документацию, и не делайте таких идиотских «оптимизаций» более.

гм. поясните, пжл, в чём идиотство. известно, что надо запрещать вещи типа ls, find.. и т.п. всё что я сделал - это расширил это правило до «всё что не разрешено явно - запрещено». что именно не так?

AndreyKl ★★★★★ ()
Ответ на: комментарий от Nastishka

гм

chmod 755 /sbin/{faillock,mkhomedir_helper,pam_console_apply,pam_tally2,pam_timestamp_check,unix_chkpwd,unix_update}

не помогло...

и какую документацию изучить?

AndreyKl ★★★★★ ()
Ответ на: комментарий от imul

у меня веб-сервера. там ничего никто кроме крона и php не запускает. никогда. или настолько редко что не проблема разрешить это руками по запросу.

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

[code]chmod 755 /sbin/{faillock,mkhomedir_helper,pam_console_apply,pam_tally2,pam_timestamp_check,unix_chkpwd,unix_update}[/code]

а что не так?

Возьмите _нормальную_ не поломанную вашими кривыми руками систему, посмотрите на то, какие на ней атрибуты на файлах, и выставите такие же. Например, unix_chkpwd и pam_timestamp_chek имеют совершенно другие атрибуты.

Ограничивать доступ надо к данным, а не к программам.

Nastishka ★★★★ ()
Ответ на: комментарий от Nastishka

Возьмите _нормальную_ не поломанную вашими кривыми руками систему, посмотрите на то, какие на ней атрибуты на файлах, и выставите такие же.

взял, поглядел, выставил

chmod 755 /sbin/{faillock,mkhomedir_helper,pam_console_apply,pam_tally2}
chmod 4755 /sbin/{pam_timestamp_check,unix_chkpwd}

полегчало,

$ crontab -e
/var/spool/cron/test: Permission denied

в логах чисто. su с верными аттрибутами..

strace останавливается на write(4, /var/spool/cron/test...Permission denied

я что-то ума не приложу, что кроме прав может мешать write писать в файл/создавать его. но права на /var/spool/cron/ я не менял. думал su недоступно, но как уже упоминал, верная установка прав (по аналогии с «чистой» машиной) не повлияла на ситуацию.

AndreyKl ★★★★★ ()
Ответ на: комментарий от imul

ну похоже на то... запускаются как обычно.. делается наверное какой-то suexec, но вроде как проблем не наблюдается, всё запускается и работает.. кроме кронтаба.. из того что нужно.

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

там демонов мало на самом деле

chkconfig --list | grep 3:on
acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off
auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off
vsftpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

всё что нужно работает, проблем не испытываю. пока что. но это тестовая конфигурация, ясно-красно. и vsftpd и httpd имеют «чистые» права, т.е. я к ним не прикасался.

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl
$ crontab -e
/var/spool/cron/test: Permission denied

Ну что же вы так, я ведь вам сказала - расставьте права как положено, то есть как на неполоманной вами системе!!!

$ ls -l `which crontab`
-rwsr-sr-x 1 root root 55720 окт.  27 09:10 /usr/bin/crontab
Неудивительно, что он у вас не работает.

Nastishka ★★★★ ()
Ответ на: комментарий от AndreyKl

Вообще, запустите лучше такую команду:

# rpm --setperms `rpm -qA`
Она восстановит вам права на все файлы, а то этот тред уже не перестает быть смешным.

Nastishka ★★★★ ()
Ответ на: комментарий от Nastishka

блин. слона то я и не заметил. Благодарю покорнейше.

AndreyKl ★★★★★ ()
Ответ на: комментарий от Nastishka

спасибо, но это не путь истинного джедая.

но спасибо ещё раз :)

AndreyKl ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.