Bug 487186 - f10 x86_64 selinux error for logrotate
f10 x86_64 selinux error for logrotate
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-02-24 12:46 EST by stanl
Modified: 2009-03-02 21:20 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-02 21:20:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description stanl 2009-02-24 12:46:52 EST
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
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 #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)
Comment 1 Daniel Novotny 2009-02-25 05:19:45 EST
SELinux policy should allow access to /var/log/ocsinventory-server for logrotate_t

assigning to selinux-policy
Comment 2 Miroslav Grepl 2009-02-25 07:56:35 EST

*** This bug has been marked as a duplicate of bug 485867 ***
Comment 3 Daniel Walsh 2009-02-25 10:34:39 EST
For some reason this directory is labeled incorrectly?

Any idea how it got created or got this label?

Comment 4 stanl 2009-02-25 11:05:41 EST
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.
Comment 5 Daniel Walsh 2009-02-25 11:19:44 EST
So what does 

ls -lZ /var/log/ocsinventory-server

Say now?
Comment 6 stanl 2009-02-25 15:06:29 EST
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
Comment 7 Daniel Walsh 2009-02-26 09:14:38 EST
matchpathcon /var/log/ocsinventory-server
Comment 8 Daniel Walsh 2009-02-26 09:15:55 EST
# semanage fcontext -l | grep ocsinv
/var/log/ocsinventory-server(/.*)?                 all files          system_u:object_r:httpd_log_t:s0
Comment 9 stanl 2009-02-26 10:55:11 EST
$ 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
Comment 10 Miroslav Grepl 2009-03-02 13:21:52 EST
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.
Comment 11 stanl 2009-03-02 20:11:52 EST
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.

Note You need to log in before you can comment on or make changes to this bug.