Description of problem: SELinux is preventing logrotate (logrotate_t) "read" to ./ocsinventory-server (httpd_sys_content_rw_t). Version-Release number of selected component (if applicable): see below How reproducible: Happens every day. Steps to Reproduce: 1. I'm not sure, it just started happening after updates and installs 2. 3. Actual results: SELinux denied access requested by logrotate. Expected results: logrotate has no issues with running due to selinux Additional info: Source Context: system_u:system_r:logrotate_t:s0-s0:c0.c1023 Target Context: system_u:object_r:httpd_sys_content_rw_t:s0 Target Objects: ./ocsinventory-server [ dir ] Source: logrotate Source Path: /usr/sbin/logrotatePort: <Unknown>Host: fedora10.sata1Source RPM Packages: logrotate-3.7.7-1.fc10 Target RPM Packages: Policy RPM: selinux-policy-3.5.13-45.fc10 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: catchall_fileHost Name: fedora10.sata1Platform: Linux fedora10.sata1 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 EST 2009 x86_64 x86_64Alert Count: 61First Seen: Fri 26 Dec 2008 04:12:30 AM MSTLast Seen: Tue 24 Feb 2009 04:05:28 AM MSTLocal ID: 0c4d11ad-ee86-45e0-8e63-d07f08307c53Line Numbers: Raw Audit Messages :node=fedora10.sata1 type=AVC msg=audit(1235473528.20:185177): avc: denied { read } for pid=24734 comm="logrotate" name="ocsinventory-server" dev=sda6 ino=3034441 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_sys_content_rw_t:s0 tclass=dir node=fedora10.sata1 type=SYSCALL msg=audit(1235473528.20:185177): arch=c000003e syscall=2 success=no exit=-13 a0=7fff8dbafe50 a1=90800 a2=ea55ed a3=3aa896da70 items=0 ppid=24732 pid=24734 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=35286 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
SELinux policy should allow access to /var/log/ocsinventory-server for logrotate_t assigning to selinux-policy
*** This bug has been marked as a duplicate of bug 485867 ***
For some reason this directory is labeled incorrectly? Any idea how it got created or got this label? /var/log/ocsinventory-server
No. I ran the restorecon -v /var/log/ocsinventory-server that the setroubleshooter recommended. Other than that the only policy settings are those that come with the packages.
So what does ls -lZ /var/log/ocsinventory-server Say now?
It returns nothing after the ./autorelabel I did on reboot to pick up the latest test kernel. That is, it returns a new command prompt immediately. It's like I don't have any access there anymore. If I run ls -lZ /var/log | less as root I get the result below: drwxr-xr-x apache root system_u:object_r:httpd_sys_content_rw_t:s0 ocsinventory-server
matchpathcon /var/log/ocsinventory-server
# semanage fcontext -l | grep ocsinv /var/log/ocsinventory-server(/.*)? all files system_u:object_r:httpd_log_t:s0
$ matchpathcon /var/log/ocsinventory-server /var/log/ocsinventory-server system_u:object_r:httpd_sys_content_rw_t:s0 # semanage fcontext -l | grep ocsinv /etc/ocsinventory/ocsinventory-reports(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 /var/lib/ocsinventory-reports(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0 /var/log/ocsinventory-server(/.*)? all files system_u:object_r:httpd_sys_script_rw_t:s0
This looks like a problem with the ocsinventory-server .spec file when you have updated from an old version ocsinvetory-server (there was defined "httpd_sys_script_rw_t" for "/var/log/ocsinvetory-server/" ) to a newer one. You can execute: # semanage fcontext -m -t httpd_log_t '/var/log/ocsinventory-server(/.*)?' # restorecon -R -v /var/log/ocsinventory-server Should fix it.
It's funny you should bring this up. After the autorelabel on boot with the latest selinux policy from updates-testing, there was one more failure for logrotate, one for another package, and there have been *zero* since. Not sure why, but I'm not complaining. Maybe this bug can be closed.