I know I have an issue with SElinux. So I am following a tutorial that will help me understand the nature of the file access problems I am having. That was I can still have SElinux enforce as supposed to just disabling it.

Basically I have set SElinux set to permissive mode, for testing, and done a file action that would fail while it is enforcing. That way I will see what the message in the log looks like. Such a line looks like this:

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'

Now since I am really new to this I refered to the tutorial and how it talks about getting audit2why to lay this out for me.

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

The grep does return the correct text. However audit2why appears to be returning "Nothing to do".

Is there something fundamental that I am doing wrong? End of the day I am trying to figure out what context to assign to some NGINX directories. I am sure I can just look them up but I wanted also to understand what I am doing as supposed to just running commands I see on the internet.

In case you are curious this is a small snippet of my web root directory context

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
  • You're feeding a type=USER_CMD log entry into audit2why, when audit2why only translates AVCs.
    – jsbillings
    Jan 23, 2016 at 4:05
  • Hey, Matt! You're first mistake is wanting to understand what SELinux is doing. You can forget about your woodworking projects because this will take up the rest of your free time.
    – drs
    Mar 13, 2016 at 15:34

2 Answers 2


Note: I am still interested in an answer to my issue but I did want to post a work-around that I am using that gives just as useful information if audit2why was working how I would have expected.

Under the Howto for SELinux on CentOS.org there is a troubleshooting section. Therein is talks about how to use sealert to give human readable information parsed from the log "/var/log/audit/audit.log". So simply running

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

allowed me to read the information I wanted and get suggestions about the proper security context for my web directories.

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'
# semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images'
# restorecon -v '/srv/dpca/www/images'

Again, if someone knows about my original question about audit2why I would still like to know.


/var/log/audit/audit.log is a binary file. You can grep for the content with

grep -a AVC /var/log/audit/audit.log | audit2why

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .