Bug 568575
Summary: | SELinux is preventing /sbin/dhclient "read" access on nm-dhclient-wlan0.conf. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | TL <bugzilla> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | dcbw, dwalsh, f.tavano, gvs234, jim.cromie, jreiser, M8R-kta9om, mgrepl, naoki, nocountryman, rado.kljucevsek, rs, sgrubb, stephent98, vojtech.vitek, willdeed |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:ea710c0456802e7a90b3e282adfae70703eb4086af2496cb6344e6c7934a7a58 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-11-03 12:31:57 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
TL
2010-02-26 03:11:13 UTC
Execute: restorecon -R -v /var/run Will fix this. Not sure how it got mislabeled. Reopen if this happens again. Hi, I've tried this proposed solution of "restorecon -R -v /var/run" as root several times. It has never fixed the problem, ad I still get it every time NetworkManager connects. Perhaps I am doing something wrong, but this problem seems stubborn and persistent. Any other ideas? Thanks. -TL bugzilla Please attach the AVC you are getting ausearch -M avc -ts recent Also what version of setroubleshoot and selinux-policy do you have installed rpm -q setroubleshoot selinux-policy Hi, Thanks for the time. We're talking Fedora right; doubtless a typo, but it doesn't seem to like capital "-M". Oh well, so I manpaged it tried some alternates, below. Also settroubleshoot and selinux stuff at bottom. Thanks. [root@localhost ~]# ausearch -M avc -ts recent -M is an unsupported option [root@localhost ~]# ausearch -m avc -ts recent <no matches> [root@localhost ~]# ausearch -m ALL -ts recent <no matches> [root@localhost ~]# ausearch -ts recent ---- time->Thu Mar 4 00:01:01 2010 type=USER_ACCT msg=audit(1267678861.928:22815): user pid=21131 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' ---- time->Thu Mar 4 00:01:01 2010 type=CRED_ACQ msg=audit(1267678861.929:22816): user pid=21131 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' ---- time->Thu Mar 4 00:01:01 2010 type=LOGIN msg=audit(1267678861.930:22817): login pid=21131 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=9 ---- time->Thu Mar 4 00:01:01 2010 type=USER_START msg=audit(1267678861.931:22818): user pid=21131 uid=0 auid=0 ses=9 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' ---- time->Thu Mar 4 00:01:01 2010 type=CRED_DISP msg=audit(1267678861.962:22819): user pid=21131 uid=0 auid=0 ses=9 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' ---- time->Thu Mar 4 00:01:01 2010 type=USER_END msg=audit(1267678861.962:22820): user pid=21131 uid=0 auid=0 ses=9 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' [root@localhost ~]# rpm -q setroubleshoot selinux-policy setroubleshoot-2.2.64-1.fc12.i686 selinux-policy-3.6.32-89.fc12.noarch Lower case -m avc was correct. Sorry about the typo. ausearch -m avc -ts today Would show any avc received today. There are newer setroubshoot and selinux-policy available. yum -y update But why do you think SELinux is blocking you? We are not seeing AVC messages? Hi, I think SELinux is blocking me because every time I connect to the network I get an "SELinux Security Alert". I just rebooted right now to sanity check after a yum update, and it did it again. Example below. I run yum update frequently and am/was updated to the latest of whatever it gives me. Here's my release info: [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19 19:10:04 UTC 2010 i686 i686 i386 GNU/Linux [root@localhost ~]# cat /etc/redhat-release Fedora release 12 (Constantine) [root@localhost ~]# rpm -q setroubleshoot selinux-policy setroubleshoot-2.2.64-1.fc12.i686 selinux-policy-3.6.32-92.fc12.noarch [root@localhost ~]# yum -y update Loaded plugins: presto, refresh-packagekit Setting up Update Process No Packages marked for Update Here's the latest avc: [root@localhost ~]# ausearch -m avc -ts today ---- time->Thu Mar 4 08:29:54 2010 type=SYSCALL msg=audit(1267709394.199:22861): arch=40000003 syscall=5 success=no exit=-13 a0=bfa6080f a1=80000 a2=1c a3=80dae40 items=0 ppid=2277 pid=29294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1267709394.199:22861): avc: denied { read } for pid=29294 comm="dhclient" name="nm-dhclient-wlan0.conf" dev=sda7 ino=2204681 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file ---- time->Thu Mar 4 08:44:00 2010 type=SYSCALL msg=audit(1267710240.265:29): arch=40000003 syscall=5 success=no exit=-13 a0=bff1b80f a1=80000 a2=1c a3=80dae40 items=0 ppid=2189 pid=2214 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1267710240.265:29): avc: denied { read } for pid=2214 comm="dhclient" name="nm-dhclient-wlan0.conf" dev=sda7 ino=2204690 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file [root@localhost ~]# Here's the security alert I've gotten "110 times" since November... Summary: SELinux is preventing /sbin/dhclient "read" access to /var/run/nm-dhclient-wlan0.conf. Detailed Description: SELinux denied access requested by dhclient. /var/run/nm-dhclient-wlan0.conf may be a mislabeled. /var/run/nm-dhclient-wlan0.conf default SELinux type is NetworkManager_var_run_t, but its current type is var_run_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. * Files created in a directory receive the file context of the parent directory by default. * The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creating a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. * Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report against this package. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon '/var/run/nm-dhclient-wlan0.conf', if this file is a directory, you can recursively restore using restorecon -R '/var/run/nm-dhclient-wlan0.conf'. Fix Command: /sbin/restorecon '/var/run/nm-dhclient-wlan0.conf' Additional Information: Source Context unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:var_run_t:s0 Target Objects /var/run/nm-dhclient-wlan0.conf [ file ] Source dhclient Source Path /sbin/dhclient Port <Unknown> Host localhost Source RPM Packages dhclient-4.1.1-5.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-92.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name restorecon Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19 19:10:04 UTC 2010 i686 i686 Alert Count 110 First Seen Sat 21 Nov 2009 02:09:41 AM EST Last Seen Thu 04 Mar 2010 08:44:00 AM EST Local ID 96adbeaf-23af-44e6-b935-7436b92bf77e Line Numbers Raw Audit Messages node=localhost type=AVC msg=audit(1267710240.265:29): avc: denied { read } for pid=2214 comm="dhclient" name="nm-dhclient-wlan0.conf" dev=sda7 ino=2204690 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file node=localhost type=SYSCALL msg=audit(1267710240.265:29): arch=40000003 syscall=5 success=no exit=-13 a0=bff1b80f a1=80000 a2=1c a3=80dae40 items=0 ppid=2189 pid=2214 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) Thanks. And running restorecon /var/run/nm-dhclient-wlan0.conf Does not change the context? Or is this file being recreated on every boot with the wrong context. How is your network being setup? Correct, I've run both: - "restorecon /var/run/nm-dhclient-wlan0.conf" and - "restorecon -R -v /var/run" several times, as root. And it still keeps coming back. Does that point to it getting recreated at reboot? I confess I'm in the dark about how this file gets created and more generally how NetworkManager wins/controls all my networking and takes over all my network files; and then on top of that how SELinux gets into the mix. I'm more used to the old fashioned "ifup wlan0" methods. So I'm looking forward to any education here. As for my networking, this is just a wlan0 wireless connection, IP assigned via DHCP from the local network AP router. Sorry I don't have anything more specific with me. I can send any config or log files you want later tonight when I get back home from work (don't have the machine in front of me). Thanks, -TL So some process on your system is creating this file incorrectly. See if you have a process running as initrc_t ps -eZ | grep initrc_t You could have an application mislabeled, potentially something that should be running as NetworkManager_t but is running as initrc_t Could you check the labels on grep NetworkManager_exec_t /etc/selinux/targeted/contexts/files/file_contexts /usr/s?bin/NetworkManager -- system_u:object_r:NetworkManager_exec_t:s0 /usr/s?bin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/wicd -- system_u:object_r:NetworkManager_exec_t:s0 /sbin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/nm-system-settings -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/NetworkManagerDispatcher -- system_u:object_r:NetworkManager_exec_t:s0 fixfiles -R NetworkManager restore Should fix labels in the NetworkManager package fixfiles restore Will fix all labels on your system. Ok here it is. I do have one process running as initrc_t. But is this bad? [root@localhost ~]# ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 1327 ? 00:00:00 qpidd Here's the rest: [root@localhost ~]# grep NetworkManager_exec_t /etc/selinux/targeted/contexts/files/file_contexts /usr/s?bin/NetworkManager -- system_u:object_r:NetworkManager_exec_t:s0 /usr/s?bin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/wicd -- system_u:object_r:NetworkManager_exec_t:s0 /sbin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/nm-system-settings -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/NetworkManagerDispatcher -- system_u:object_r:NetworkManager_exec_t:s0 [root@localhost ~]# fixfiles -R NetworkManager restore [root@localhost ~]# I also ran "fixfiles restore". No although if Fedora ships qpidd, we probably want to write a policy for it. Next time you reboot please report if the problem comes back. I still think the problem might be in an init script or a dbus script that is not transitioning properly. ALthough you are the only one I have reporting the problem now. Hi, so I rebooted -- and the problem came right back again. Here's the command output again: [root@localhost ~]# ausearch -m avc -ts today ---- time->Fri Mar 5 14:13:52 2010 type=SYSCALL msg=audit(1267816432.902:69): arch=40000003 syscall=5 success=no exit=-13 a0=bf83e80f a1=80000 a2=1c a3=80dae40 items=0 ppid=2189 pid=6916 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1267816432.902:69): avc: denied { read } for pid=6916 comm="dhclient" name="nm-dhclient-wlan0.conf" dev=sda7 ino=2204690 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file ---- time->Fri Mar 5 14:44:11 2010 type=SYSCALL msg=audit(1267818251.505:29): arch=40000003 syscall=5 success=no exit=-13 a0=bfa6580f a1=80000 a2=1c a3=80dae40 items=0 ppid=2301 pid=2326 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1267818251.505:29): avc: denied { read } for pid=2326 comm="dhclient" name="nm-dhclient-wlan0.conf" dev=sda7 ino=2204690 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file [root@localhost ~]# ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 1353 ? 00:00:00 qpidd [root@localhost ~]# grep NetworkManager_exec_t /etc/selinux/targeted/contexts/files/file_contexts /usr/s?bin/NetworkManager -- system_u:object_r:NetworkManager_exec_t:s0 /usr/s?bin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/wicd -- system_u:object_r:NetworkManager_exec_t:s0 /sbin/wpa_supplicant -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/nm-system-settings -- system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/NetworkManagerDispatcher -- system_u:object_r:NetworkManager_exec_t:s0 Also, not sure if this relevant or not, but regarding the 'settroubleshoot' program you were asking about, I'm now getting this error, in /var/log/messages: Mar 5 14:44:47 localhost setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.79:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Thanks, TL Dan, Do you have any idea what program is creating this file? Yeah, it should be NM itself when bringing up a connection. But NM has been doing that since Fedora 9, so nothing I can think of has changed here on the NM side WRT to how the DHCP config files are created. Steve is there an audit rule that we could add to watch for the creation of this file? I would use something like this: -w /etc/shadow -p wa in /etc/audit/audit.rules. Even though its a watch on the shadow file, it will trigger the audit system to add additional records to AVCs without as much performance impact as a syscall watch would. But the problem here is we have a rogue process creating this file. Probably running as initrc_t but we do not know when this happens. OK, may add this to /etc/audit/audit.rules: -a exit,always -F dir=/var/run -F perm=wa -k wlan then delete the file and reboot. Search using: ausearch --start today -k wlan -f wlan0.conf -i Remove the rule once you have the answer. This resolved itself for me after a reboot. I'm seeing this too, but not just read and not just dhclient: avc: denied { write } for pid=3017 comm="dhclient" name="dhclient-wlan0.pid" dev=dm-6 ino=76573 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file avc: denied { read } for pid=3017 comm="dhclient" name="dhclient-wlan0.pid" dev=dm-6 ino=76573 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file avc: denied { read } for pid=18582 comm="NetworkManager" name="dhclient-wlan0.pid" dev=dm-6 ino=76573 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file avc: denied { unlink } for pid=18582 comm="NetworkManager" name="dhclient-wlan0.pid" dev=dm-6 ino=76573 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file Note that I have wicd installed, and occasionally switch between it and NetworkManager, as each works in some environment where the other doesn't. restorecon -R -v /var/run Then reopen if it happens again. I do not have NetworkManager installed, yet my selinux avc denial report hashed to this bug. My configuration is as described in Bug 637583. To reproduce these denials: 1. sudo restorecon -R -v /var/run 2. System->Shutdown->Suspend then resume 3. system-control-network 4. Deactivate 5. Activate Results: SELinux security alert appears immediately Interestly, dhclient-eth0.pid has the correct label when I check it after this: [stephent@walnut run]$ sudo restorecon -R -n -v /var/run [stephent@walnut run]$ ls -Z dhclient-eth0.pid -rw-r--r--. root root unconfined_u:object_r:dhcpc_var_run_t:s0 dhclient-eth0.pid [stephent@walnut ~]$ rpm -qa 'Net*' 'selinux*' 'pm*' 'dhc*' initscripts | sort dhclient-4.1.1-23.P1.fc13.x86_64 initscripts-9.12.1-1.fc13.x86_64 NetworkManager-glib-0.8.1-6.git20100831.fc13.x86_64 pm-utils-1.2.6.1-1.fc13.x86_64 selinux-policy-3.7.19-57.fc13.noarch selinux-policy-targeted-3.7.19-57.fc13.noarch [stephent@walnut ~]$ sudo ausearch -m avc -ts 11:02:10 ---- time->Sat Oct 2 11:02:10 2010 type=SYSCALL msg=audit(1286042530.503:106): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9f17ef28 a1=80000 a2=1b6 a3=0 items=0 ppid=19277 pid=19324 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1286042530.503:106): avc: denied { read } for pid=19324 comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file ---- time->Sat Oct 2 11:02:10 2010 type=SYSCALL msg=audit(1286042530.505:107): arch=c000003e syscall=2 success=no exit=-13 a0=1d06520 a1=80000 a2=1b6 a3=0 items=0 ppid=19277 pid=19324 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1286042530.505:107): avc: denied { read } for pid=19324 comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file ---- time->Sat Oct 2 11:02:10 2010 type=SYSCALL msg=audit(1286042530.505:108): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9f17ef28 a1=80241 a2=1a4 a3=0 items=0 ppid=19277 pid=19324 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="dhclient" exe="/sbin/dhclient" subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1286042530.505:108): avc: denied { write } for pid=19324 comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file [stephent@walnut ~]$ Could you try to update to the latest selinux-policy selinux-policy-targeted-3.6.32-125.fc12.noarch selinux-policy-3.6.32-125.fc12.noarch and please reopen if it happens again with this policy. Thanks. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This is should have been closed automatically by bugzilla |