Почему audit2why нечего делать?

Я знаю, что у меня проблема с SElinux. Поэтому я следую учебному пособию , который поможет мне понять характер проблем с доступом к файлам, которые у меня возникают. Это я все еще могу использовать SElinux, как предполагалось, просто отключив его.

В принципе, я установил набор SElinux в разрешающий режим для тестирования и выполнил действие файла, которое не срабатывало при его соблюдении. Таким образом, я увижу, как выглядит сообщение в журнале. Такая строка выглядит так:

type=USER_CMD msg=audit(1452912989.069:324790): pid=66581 uid=1001 auid=1001 ses=1352 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/srv/dpca/www" cmd=7461696C202F7661722F6C6F672F61756469742F61756469742E6C6F67 terminal=pts/0 res=success' 

Теперь, поскольку я действительно новичок в этом, я ссылаюсь на учебник и как он говорит о том, как получить audit2why чтобы выложить это для меня.

 [matt@localhost www]$ sudo grep 1452912989.069:324790 /var/log/audit/audit.log | audit2why Nothing to do 

grep возвращает правильный текст. Однако audit2why кажется, возвращает «ничего не делать».

Есть ли что-то фундаментальное, что я делаю неправильно? Конец дня Я пытаюсь выяснить, какой контекст назначить для некоторых каталогов NGINX. Я уверен, что могу просто взглянуть на них, но я хотел бы также понять, что я делаю, как предполагалось, чтобы просто запускать команды, которые я вижу в Интернете.

Если вам интересно, это небольшой фрагмент моего контекста корневого каталога в Интернете

 drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 administrator drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 bin drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 cache 

Примечание. Меня все еще интересует ответ на мою проблему, но я хочу опубликовать обход, который я использую, и дает как полезную информацию, если audit2why работает, как я ожидал.

В разделе Howto для SELinux на CentOS.org есть раздел устранения неполадок. В нем рассказывается о том, как использовать sealert чтобы получить sealert для человека информацию из журнала «/var/log/audit/audit.log». Так просто бегаем

 sudo sealert -a /var/log/audit/audit.log > ~/logfile.txt 

позволил мне прочитать информацию, которую я хотел, и получить предложения о правильном контексте безопасности для моих веб-каталогов.

 SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images. ***** Plugin httpd_write_content (92.2 confidence) suggests *************** If you want to allow php-fpm to have write access on the images directory Then you need to change the label on '/srv/dpca/www/images' Do # semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images' # restorecon -v '/srv/dpca/www/images' 

Опять же, если кто-то знает о моем первоначальном вопросе о audit2why я все равно хотел бы знать.