Description of problem: setroubleshoot service fails to start, so setroubleshoot desktop notifier is not active. User may be unaware of security issues. Version-Release number of selected component (if applicable): # rpm -qa | egrep -i 'setroubleshoot|selinux' selinux-policy-3.3.1-33.fc9.noarch libselinux-devel-2.0.61-1.fc9.i386 libselinux-2.0.61-1.fc9.i386 selinux-policy-targeted-3.3.1-33.fc9.noarch setroubleshoot-2.0.6-1.fc9.noarch setroubleshoot-plugins-2.0.4-5.fc9.noarch setroubleshoot-server-2.0.6-1.fc9.noarch libselinux-python-2.0.61-1.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Boot system, or As root: start or restart setroubleshoot service 2. Check /var/log/messages Actual results: setroubleshoot service fails to start Expected results: setroubleshoot service should start without errors Additional info: ### Messages appearing on console (system at runlevel 5): --------------------------------------------------------- [root@athelas ~]# service setroubleshoot status setroubleshootd dead but pid file exists [root@athelas ~]# service setroubleshoot stop Stopping setroubleshootd: [FAILED] [root@athelas ~]# service setroubleshoot start Starting setroubleshootd: [ OK ] [root@athelas ~]# error: cannot open Packages index using db3 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm ### Messages in /var/log/messages: ---------------------------------- Apr 11 21:33:34 athelas setroubleshoot: [rpc.ERROR] attempt to open server connection failed: Connection refused ... Apr 11 22:24:56 athelas setroubleshoot: [program.ERROR] failed to get filesystem list from rpm#012Traceback (most recent call last):#012 File "/usr/lib/python2.5/site-packages/setroubleshoot/util.py", line 240, in get_standard_directories#012 h = ts.dbMatch("name", "filesystem").next()#012TypeError: rpmdb open failed ### File modes, owner & contexts [root@athelas ~]# ls -l --context /var/lib/rpm -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Basenames -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Conflictname -rw-r--r-- root root system_u:object_r:rpm_var_lib_t:s0 __db.001 -rw-r--r-- root root system_u:object_r:rpm_var_lib_t:s0 __db.002 -rw-r--r-- root root system_u:object_r:rpm_var_lib_t:s0 __db.003 -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Dirnames -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Filemd5s -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Group -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Installtid -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Name -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Packages -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Providename -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Provideversion -rw-r--r-- root root system_u:object_r:rpm_var_lib_t:s0 Pubkeys -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Requirename -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Requireversion -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Sha1header -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Sigmd5 -rw-r--r-- root root unconfined_u:object_r:var_lib_t:s0 Triggername ### Audit messages ------------------ # grep setr /var/log/audit/audit.log | tail type=AVC msg=audit(1207963987.513:18): avc: denied { read } for pid=2036 comm="setroubleshootd" name="Packages" dev=sda8 ino=20666 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1207963987.513:18): arch=40000003 syscall=5 success=no exit=-13 a0=9bb3ca8 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=2036 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0 key=(null) type=AVC msg=audit(1207963987.513:19): avc: denied { read } for pid=2036 comm="setroubleshootd" name="Packages" dev=sda8 ino=20666 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1207963987.513:19): arch=40000003 syscall=5 success=no exit=-13 a0=9bb3ca8 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=2036 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0 key=(null) type=AVC msg=audit(1207967096.307:52): avc: denied { read } for pid=3740 comm="setroubleshootd" name="Packages" dev=sda8 ino=20666 scontext=unconfined_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1207967096.307:52): arch=40000003 syscall=5 success=no exit=-13 a0=8bba4c0 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=3740 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="setroubleshootd" exe="/usr/bin/python" subj=unconfined_u:system_r:setroubleshootd_t:s0 key=(null) type=AVC msg=audit(1207967096.307:53): avc: denied { read } for pid=3740 comm="setroubleshootd" name="Packages" dev=sda8 ino=20666 scontext=unconfined_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1207967096.307:53): arch=40000003 syscall=5 success=no exit=-13 a0=8bba4c0 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=3740 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="setroubleshootd" exe="/usr/bin/python" subj=unconfined_u:system_r:setroubleshootd_t:s0 key=(null) type=AVC msg=audit(1207967096.307:54): avc: denied { read } for pid=3740 comm="setroubleshootd" name="Packages" dev=sda8 ino=20666 scontext=unconfined_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1207967096.307:54): arch=40000003 syscall=5 success=no exit=-13 a0=8bba4c0 a1=8000 a2=0 a3=8000 items=0 ppid=1 pid=3740 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="setroubleshootd" exe="/usr/bin/python" subj=unconfined_u:system_r:setroubleshootd_t:s0 key=(null)
Dan, do you know why these denials are occurring? Was there a policy change?
restorecon -R -v /var/lib/rpm Mislabed rpm directory setroubleshoot should have told you that, oops never mind.
Sweet. Looks ok now. # restorecon -R -v /var/lib/rpm restorecon reset /var/lib/rpm/Name context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:rpm_var_lib_t:s0 restorecon reset /var/lib/rpm/Providename context unconfined_u:object_r:var_lib_t:s0->system_u:object_r:rpm_var_lib_t:s0 ... # service setroubleshoot status setroubleshootd dead but pid file exists # service setroubleshoot restart Stopping setroubleshootd: [FAILED] Starting setroubleshootd: [ OK ] Did I cause the mislabeling, or is it an installation problem? I had some problems with rpm database corruption after installing, and ran 'rpmdb --rebuilddb' to fix it. Other than that, I haven't been mucking about in there.
So that probably blew away the directory and recreated it without setting the context correctly. rpmdb should either not destroy the directory or execute restorecon /var/lib/rpm when it recreates it.
Right, I'm not terribly surprised that rebuilddb blows away selinux contexts, I'm only surprised that this hasn't come up until now :) Will look into it.
Bzzzt! rpm --rebuilddb does not destroy and recreate /var/lib/rpm, and never has done that.
Dropping to F9Target -- this isn't something on the install (or even normal) path. Although the fix is probably just adding bits to preserve the xattrs in rpmdb/rpmdb.c:rpmdbMoveDatabase() like is done with uid/gid/mode/mtime
Fixed upstream
Oh and as for comment #6: Bzzt! rename() doesn't (re)set security contexts based on destination path.
rmdir(2), not rename(2), was cited as the cause of "unconfined_u". My statement wrto the rpm implementation was both accurate and true. OTOH I'm not terribly surprised that rpm and selinux are still having issues 4+ years later myself. Lord knows there's no viable packaging for anything but monolithic policy _STILL_. But I digress ...
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is fixed in the new rpm version in rawhide.
Fixed in F10, doesn't seem worth the effort to backport to F9.