Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
Show us a relevant audit.log entry. – Iain Apr 4 '14 at 11:36
Good point, has been added @Iain – Craig Francis Apr 4 '14 at 11:46

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.