Bug 593478 - [abrt] crash in policycoreutils-python-2.0.82-4.fc12: audit2allow:43:__parse_options:ValueError: unable to open /etc/selinux/targeted/policy/policy.24: Permission denied
Summary: [abrt] crash in policycoreutils-python-2.0.82-4.fc12: audit2allow:43:__parse_...
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:f41ab650
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-18 21:37 UTC by Brian Whitehead
Modified: 2010-05-21 13:27 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-05-21 13:27:31 UTC


Attachments (Terms of Use)
File: backtrace (572 bytes, text/plain)
2010-05-18 21:37 UTC, Brian Whitehead
no flags Details

Description Brian Whitehead 2010-05-18 21:37:44 UTC
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>

Comment 1 Brian Whitehead 2010-05-18 21:37:45 UTC
Created attachment 414969 [details]
File: backtrace

Comment 2 Daniel Walsh 2010-05-19 13:03:44 UTC
Brian is your machine properly labeled?

/etc/selinux/targeted/policy/policy.24 usually readable by users?

Comment 3 Brian Whitehead 2010-05-19 13:51:01 UTC
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

Comment 4 Brian Whitehead 2010-05-19 13:54:20 UTC
(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

Comment 5 Daniel Walsh 2010-05-19 18:08:26 UTC
chmod +r /etc/selinux/targeted/policy/policy.24

Comment 6 Daniel Walsh 2010-05-19 18:09:02 UTC
Did you have all the bugs on user_home_t?

Comment 7 Brian Whitehead 2010-05-19 20:33:09 UTC
(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.

Comment 8 Brian Whitehead 2010-05-19 20:34:16 UTC
(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.

Comment 9 Daniel Walsh 2010-05-19 20:56:38 UTC
I think you might have an entry in /etc/passwd that SELinux thinks is a user.

grep share /etc/passwd

Comment 10 Brian Whitehead 2010-05-19 22:19:20 UTC
(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

Comment 11 Daniel Walsh 2010-05-21 13:27:31 UTC
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.


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