abrt 1.0.9 detected a crash. architecture: x86_64 cmdline: /usr/bin/python -E /usr/bin/audit2allow -i /tmp/tmp1dbfLk component: policycoreutils executable: /usr/bin/audit2allow kernel: 2.6.32.11-99.fc12.x86_64 package: policycoreutils-python-2.0.82-4.fc12 reason: audit2allow:43:__parse_options:ValueError: unable to open /etc/selinux/targeted/policy/policy.24: Permission denied release: Fedora release 12 (Constantine) backtrace ----- audit2allow:43:__parse_options:ValueError: unable to open /etc/selinux/targeted/policy/policy.24: Permission denied Traceback (most recent call last): File "/usr/bin/audit2allow", line 344, in <module> app.main() File "/usr/bin/audit2allow", line 334, in main self.__parse_options() File "/usr/bin/audit2allow", line 43, in __parse_options from optparse import OptionParser ValueError: unable to open /etc/selinux/targeted/policy/policy.24: Permission denied Local variables in innermost frame: self: <__main__.AuditToPolicy instance at 0x17be6c8>
Created attachment 414969 [details] File: backtrace
Brian is your machine properly labeled? /etc/selinux/targeted/policy/policy.24 usually readable by users?
I did the /.autorelabel twice yesterday because I was seeing many selinux denials. They actually got worse after the relabel. Interestingly, this policy.24 file doesn't even exist. -(0)> ls -la /etc/selinux/targeted/policy/ total 1828 drwxr-xr-x 2 root root 4096 May 17 16:02 ./ drwxr-xr-x 5 root root 4096 May 17 16:02 ../ -rw-r--r-- 1 root root 1843414 May 17 16:02 policy.21
(In reply to comment #3) > I did the /.autorelabel twice yesterday because I was seeing many selinux > denials. They actually got worse after the relabel. > > Interestingly, this policy.24 file doesn't even exist. > > -(0)> ls -la /etc/selinux/targeted/policy/ > total 1828 > drwxr-xr-x 2 root root 4096 May 17 16:02 ./ > drwxr-xr-x 5 root root 4096 May 17 16:02 ../ > -rw-r--r-- 1 root root 1843414 May 17 16:02 policy.21 Sorry, mispoke. I was on the wrong system. The file is there --(0)> ls -laZ /etc/selinux/targeted/policy/ drwxr-xr-x. root root system_u:object_r:semanage_store_t:s0 ./ drwxr-xr-x. root root system_u:object_r:selinux_config_t:s0 ../ -rw-r-----. root root unconfined_u:object_r:semanage_store_t:s0 policy.24 --(0)> sudo restorecon /etc/selinux/targeted/policy/policy.24 --(0)> ls -laZ /etc/selinux/targeted/policy/ drwxr-xr-x. root root system_u:object_r:semanage_store_t:s0 ./ drwxr-xr-x. root root system_u:object_r:selinux_config_t:s0 ../ -rw-r-----. root root unconfined_u:object_r:semanage_store_t:s0 policy.24
chmod +r /etc/selinux/targeted/policy/policy.24
Did you have all the bugs on user_home_t?
(In reply to comment #5) > chmod +r /etc/selinux/targeted/policy/policy.24 Done. I'm curious how it got changed. I confirmed that `rpm --setperms selinux-policy-targeted` set it back to 644.
(In reply to comment #6) > Did you have all the bugs on user_home_t? Yes, I got about 50 denials after touching /.autorelabel and rebooting.
I think you might have an entry in /etc/passwd that SELinux thinks is a user. grep share /etc/passwd
(In reply to comment #9) > I think you might have an entry in /etc/passwd that SELinux thinks is a user. > > grep share /etc/passwd Is it looking at the UID > 500 or an account with a home in /usr/share with a valid shell? smolt:x:495:487:Smolt:/usr/share/smolt:/sbin/nologin cacti:x:486:469::/usr/share/cacti:/sbin/nologin netdisco:x:501:501::/usr/share/netdisco/:/bin/sh
Both. Can you change netdisco to /sbin/nologin or its uid < 501. This should clean up the problem. After doing this, execute # genhomedircon # restorecon -R -v /usr/share In F13 the genhomedircon functionality will be turned off by default. So this will not happen.