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

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

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

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

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

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

а что не так?

спасибо.

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

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

гм

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

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

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

Ты собрался работать *только* рутом?

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

[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 имеют совершенно другие атрибуты.

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

Демоны запускаются от рута?

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

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

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 недоступно, но как уже упоминал, верная установка прав (по аналогии с «чистой» машиной) не повлияла на ситуацию.

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

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

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 имеют «чистые» права, т.е. я к ним не прикасался.

$ 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

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

# rpm --setperms `rpm -qA`

Извиняюсь, rpm --setperms `rpm -qa`. Ошиблась в регистре.

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

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

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

кстати говоря, вот тут Linux Local Privilege Escalation via SUID /proc/pid/mem Write (комментарий)

эксплойт, от которого данный подход вполне себе спасает.