With the directory structure:


Where Apache needs at least the following access:

app: read-only access, but read-write is fine (files already chmod 0644)
files: read-write access
logs: read-write access

Where the following two rules have been setup via:

/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/www/live/.*/.*";
/usr/sbin/semanage fcontext -a -t httpd_log_t "/www/live/.*/logs(/.*)?";

/sbin/restorecon -vr "/www";

Which are applied, and seem to be working fine... however LogRotate isn't happy.

The LogRotate config is currently:

/www/live/*/logs/*access_log /www/live/*/logs/*access_log_443 {
    rotate 52
        /usr/sbin/apachectl graceful > /dev/null

However, this seems to be blocked by SELinux, with entries appearing in the audit.log when its trying to hit the inode related to the /www/live folder (262146 in the example below)... as its presumably trying to list the folders in /www/live/.

type=AVC msg=audit(1396579563.324:316060): avc:  denied  { read } for  pid=12336 comm="logrotate" name="live" dev=dm-0 ino=262146 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=SYSCALL msg=audit(1396579563.324:316060): arch=c000003e syscall=2 success=no exit=-13 a0=7fff2cef68b0 a1=90800 a2=7fff2cef6b5a a3=8 items=0 ppid=12334 pid=12336 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=35531 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

So what context should I set this parent directory?

/usr/sbin/semanage fcontext -a -t default_t "/www(/.*)";

Where I know default_t doesn't work, nor does var_t... and for reference I don't really care what can see these folders, as they are already chmod 0755.

And for bonus points... is there an easy way to see the full list of permissions a program has? I know LogRotate must be able to access httpd_log_t and var_log_t.

The annoying thing is that running LogRotate manually seems to bypass these restrictions, as I assume that its inheriting the users permissions (unlike when it runs via cron).

  • Show us a relevant audit.log entry.
    – user9517
    Apr 4, 2014 at 11:36
  • Good point, has been added @Iain Apr 4, 2014 at 11:46

1 Answer 1


Not confirmed if this is the right answer yet...

/usr/sbin/semanage fcontext -a -t sysfs_t "/www(/.*)";
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/www/live/.*/.*";
/usr/sbin/semanage fcontext -a -t httpd_log_t "/www/live/.*/logs(/.*)?";
/sbin/restorecon -vr "/www";

There the sysfs_t is the important bit.

I can find the domains that LogRotate can use with:

sesearch -s logrotate_t -SA

Doing a quick search for the "read" (not just "open") permission for "dir":

sesearch -s logrotate_t -SA -c dir -p read | sort

Then scanning though the list, I would say that sysfs_t is the most appropriate.

A problem I did find is that if I run /usr/sbin/logrotate myself, it inherits the root account context:

id -Z

So it automatically gets "unconfined" access (i.e. full access)... so to test, I found that using the following, while not perfect, did kind of work:

sandbox /usr/sbin/logrotate -d /etc/logrotate.conf

I also found out about newrole and runcon, both of which need to be installed separately on a RedHat/CentOS system via:

yum install policycoreutils-newrole

newrole -r system_r -t logrotate_t
runcon -r system_r -t logrotate_t /usr/sbin/logrotate -d /etc/logrotate.conf

But both of these were giving me permission denied errors (probably due to the transition not being allowed):


Something else I found useful:

yum install setools-console

seinfo -usystem_u -x
seinfo -rsystem_r -x
seinfo -tlogrotate_t -x

seinfo -tsysfs_t -x

And to check the list of rules I've created on the system:

cat /etc/selinux/targeted/contexts/files/file_contexts.local

For more information on SELinux, I found these 17 tutorials very helpful:


Personally I have found all these programs very inconsistent, and can understand why most people just disable SELinux by default... e.g.

  • You can't have a space after the seinfo options -u/r/t
  • You need to install extra packages to get seinfo and newrole
  • You can't easily run a program manually under a given context (for testing purposes).
  • The audit.log file uses timestamps, so instead try ausearch -m avc --start today.
  • No naming convention with the many programs used (e.g. matchpathcon).
  • I wouldn't say the output (or operation) of audit2allow was obvious.

Which is a shame, as it seems to be a a very powerful system overall.

You must log in to answer this question.

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