Назад | Перейти на главную страницу

httpd пытается получить доступ к файлам сеанса, принадлежащим root

Изучая причину зависания / сбоя сервера, я обнаружил много сообщений selinux в / var / log / messages. Например:

setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /tmp/sess_s5etafvc5ito5qi9icvpc17vi5. For complete SELinux messages. run sealert -l 9d054e4e-fc34-41a3-8fc5-4015026d2c6c

Не уверен, что это актуально, но группе из них предшествуют или следуют многие строки

audispd: queue is full - dropping event

В любом случае, выполнение предложенной команды sealert дает

SELinux is preventing /usr/sbin/httpd from getattr access on the file /tmp/sess_aa0iif62mu7nd4a4hb4g72slv3.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that httpd should be allowed getattr access on the sess_aa0iif62mu7nd4a4hb4g72slv3 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

ls -l показывает, что он принадлежит root

-rw-------. 1 root root 0 Dec 2 05:03 sess_aa0iif62mu7nd4a4hb4g72slv3

Я плохо разбираюсь в каталоге или сеансах / tmp. Существуют файлы сеанса, принадлежащие httpd, так зачем httpd пытаться получить доступ к файлам сеанса, принадлежащим root? Почему вообще существуют файлы сеансов, принадлежащие root? Об этом нужно беспокоиться или исправить? Могут ли сотни или тысячи из них привести к блокировке сервера / панике ядра?

Кажется, что у вас есть движок приложения, такой как PHP, работающий от имени пользователя root. Подтвердите пользователя, владеющего процессом для каждого из ваших серверных демонов, с помощью ps или top.