Created attachment 436985 [details] Message "Error while checking policy version." Description of problem: Message "Error while checking policy version." appears in the SELinux dialog after clicked on the SysTray icon or menu on System/SELinux-Fehlersuche (german settings). Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Start SELinux dialog. 2. 3. Actual results: Message "Error while checking policy version." Expected results: No such message. Additional info: see attached screenshot.
$ sestatus -v; id -Z SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted Process contexts: Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0 File contexts: Controlling term: unconfined_u:object_r:user_devpts_t:s0 /etc/passwd system_u:object_r:etc_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:init_exec_t:s0 /sbin/mingetty system_u:object_r:getty_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0 /lib/libc.so.6 system_u:object_r:lib_t:s0 -> system_u:object_r:lib_t:s0 /lib/ld-linux.so.2 system_u:object_r:lib_t:s0 -> system_u:object_r:ld_so_t:s0 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
This error indicates for some reason your machine is not able to ask yum for the latest available selinux-policy package. It is doing the equivalent of yum list selinux-policy and failing for some reason.
Yes, the output of "yum list selinux-policy" as my user contains the following. Could not set cachedir: [Errno 13] Keine Berechtigung: '/var/tmp/yum-raphael-WyIFRv' A similiar message for the command executed as root does not appear at all. So I guess some problem with access rights to /var/tmp. Thanks for your help.
Created attachment 437195 [details] strace /usr/bin/sealert -b Sorry, fixing access rights to /var/tmp did not help. Here is the output of "strace /usr/bin/sealert -b", it looks strange due to a lot of not found python errors. I tried to reinstall selinux-policy and setroubleshoot packages: selinux-policy-3.7.19-41.fc13.noarch setroubleshoot-2.2.91-1.fc13.x86_64
I am reopening this bug cause problem is not solved.
Created attachment 438317 [details] Print-screen.jpg NB: I am still unsure if this is the proper way to include a print-screen in a comment. If not, instruct how to proceed, thank you. from the shell, all seem fine compared to the OP [root@localhost ~]# yum list selinux-policy Loaded plugins: fastestmirror, presto, refresh-packagekit Loading mirror speeds from cached hostfile * fedora: www.ftp.ne.jp * livna: rpm.livna.org * rpmfusion-free: mirrors.163.com * rpmfusion-free-updates: mirrors.163.com * rpmfusion-nonfree: mirrors.163.com * rpmfusion-nonfree-updates: mirrors.163.com * updates: www.ftp.ne.jp Installed Packages selinux-policy.noarch 3.7.19-44.fc13 @updates However the SELinux Security Alert keeps displaying the message "Error while checking policy version". See attachment "print-screen.jpg"
Could it be that it has nothing to do with the selinux-policy version? Maybe a bug in setroubleshoot? Changing product to raise suspicion ...
Code generating the message (/usr/lib/python2.6/site-packages/setroubleshoot/browser.py, line 298): self.updaterpipe.poll() if self.updaterpipe.returncode != 0: self.current_policy_label.set_markup("<small><b>%s</b></small>" % _("Error while checking policy version.")) yield False In line 279, updaterpipe is defined as: self.updaterpipe = Popen(["/usr/bin/python", "/usr/share/setroubleshoot/updater.py"], stdout=PIPE) I run in my system: yum list selinux-policy python /usr/share/setroubleshoot/updater.py The two commands return 0. Then, I run sealert and the message "Error while checking policy version" is gone. Now the message "Policy version: 3.7.19-44.fc13" appear. My opinion: problems with the cache of yum... Sorry by my english, it is not my native language...
(In reply to comment #8) Confirmed. The python call seems to return something else than 0 at my machine. $ python /usr/share/setroubleshoot/updater.py Geladene Plugins: auto-update-debuginfo, presto, refresh-packagekit current: 3.7.19-44.fc13 Found 12 installed debuginfo package(s) Enabling fedora-debuginfo: Fedora 13 - x86_64 - Debug Enabling rpmfusion-nonfree-debuginfo: RPM Fusion for Fedora 13 - Nonfree - Debug Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 13 - Free - Updates Debug Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 13 - Free - Debug Enabling updates-debuginfo: Fedora 13 - x86_64 - Updates - Debug Enabling rpmfusion-nonfree-updates-debuginfo: RPM Fusion for Fedora 13 - Nonfree - Updates Debug done
(In reply to comment #9) > (In reply to comment #8) > Confirmed. The python call seems to return something else than 0 at my machine. > > $ python /usr/share/setroubleshoot/updater.py > Geladene Plugins: auto-update-debuginfo, presto, refresh-packagekit > current: 3.7.19-44.fc13 > Found 12 installed debuginfo package(s) > Enabling fedora-debuginfo: Fedora 13 - x86_64 - Debug > Enabling rpmfusion-nonfree-debuginfo: RPM Fusion for Fedora 13 - Nonfree - > Debug > Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 13 - Free - > Updates Debug > Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 13 - Free - Debug > Enabling updates-debuginfo: Fedora 13 - x86_64 - Updates - Debug > Enabling rpmfusion-nonfree-updates-debuginfo: RPM Fusion for Fedora 13 - > Nonfree - Updates Debug > done Please, you can run the command more a time and check the return? Maybe a temporary yum cache problem be a culprit...
(In reply to comment #10) Tried that for several times now.
(In reply to comment #11) > (In reply to comment #10) > > Tried that for several times now. Thanks. My knowledge about python scripts is pretty limited, but IMO yum cache is the culprit. In my system that bug disappear like magic... Maybe a "yum clean all", as root, resolve the problem...
(In reply to comment #12) Yeah. Thanks, yum clean metadata fixed it. I don't know how to reproduce the broken metadata.
I ran "yum clean metadata" and "yum clean all", but the setroubleshoot browser still shows the message "Error while checking policy version".
Did you stop and restart it?
I am unable to run updater.py. Here is the paste from my terminal: Installed Packages selinux-policy.noarch 3.7.19-44.fc13 @updates-testing [Donald@Zonotrichia ~]$ 'python /usr/share/setroubleshoot/updater.py' bash: python /usr/share/setroubleshoot/updater.py: No such file or directory [Donald@Zonotrichia ~]$ ls /usr/share/setroubleshoot gui SetroubleshootFixit.py SetroubleshootFixit.pyo updater.pyc plugins SetroubleshootFixit.pyc updater.py updater.pyo [Donald@Zonotrichia ~]$ su -c '/usr/share/setroubleshoot/updater.py' Password: /usr/share/setroubleshoot/updater.py: line 6: from: command not found /usr/share/setroubleshoot/updater.py: line 7: syntax error near unexpected token `domain' /usr/share/setroubleshoot/updater.py: line 7: `gettext.install(domain = get_config('general', 'i18n_text_domain'),' [Donald@Zonotrichia ~]$ su -c '/usr/share/setroubleshoot/updater.py' Password: /usr/share/setroubleshoot/updater.py: line 6: from: command not found /usr/share/setroubleshoot/updater.py: line 7: syntax error near unexpected token `domain' /usr/share/setroubleshoot/updater.py: line 7: `gettext.install(domain = get_config('general', 'i18n_text_domain'),' [Donald@Zonotrichia ~]$
Yes, I did restart the browser. It was not open when I ran the yum clean commands. After the cleaning, I ran sealert and the browser opened with the error message displayed. Would it make a difference if I reboot?
I had not to restart. Just executed the clean command as root and afterwards, sealert is okay for the not-root user.
(In reply to comment #16) Do it without the quotes in the command. python /usr/share/setroubleshoot/updater.py
OK, I executed updater.py as a normal user as Raphael instructed, and I guess it just shows me I'm up-to-date. I tried deep cleaning with "yum clean all --enablerepo=updates-testing", but the browser still can't find the policy version.
Donald, Can you check ~/.xsession-errors and see if there are any errors reported there. Or kill the window and in a terminal execute sealert -s And see if it reports any problems.
Could you please open a new bug? Because I am not interested in special user support. For me, the problem seems solved. Thanks.
Raphael, is this issue for special user support for you? Two other users reported that they had the same problem - and so do I. It is nice that you have found a workaround, but that doesn't mean the problem is solved. We should try to understand the problem and find a solution so the problem doesn't appear in the first place (or in the worst case that the workaround is applied automatically).
Forgot to say: I think this can be one of the reasons people keep filing reports on for example bug 607399, bug 610527, bug 610314, bug 610521 and bug 612327 even though fixes apparently have been fixed.
(In reply to comment #23) Mads, I am afraid that I can not give more information on how to reproduce the issue. Yes, the workaround did it for me and I have no more need for user support. (In reply to comment #24) Dunno about those other bugs. Sorry.
I have managed to clean up my system enough to where "sealert -s" returns no error in the terminal and opens the browser, but the browser still can't read the policy version.
The real cause of the problem is in setroubleshoot/browser.py when self.updaterpipe.poll() returns returncode which is None because the process hasn't terminated yet (because the external command takes more than 1 second) - that value is however not used anyway. But self.updaterpipe.returncode is also None which isn't zero, and that causes the error message. Perhaps the intention was to call self.updaterpipe.wait() which waits until the process has terminated and the returncode thus isn't None? Or perhaps the condition should be changed to "if self.updaterpipe.returncode:" so a value of None doesn't cause an error message? That makes it work for me, but I'm not sure that follows the intent of the code - especially regarding threading and blocking. setroubleshoot-2.2.91-1.fc13.i686
Problem occured again. I fixed it with "yum clean metadata". Could it be that the issue results from a bug of metadata going corrupted, maybe in yum code itself? I remember several refreshes of repositories cache were done.
(In reply to comment #28) Yes. "yum update" is the cause. It makes the metadata corrupted and "sealert -b" will show the well known error. After "yum clean metadata" all is well again. Please let me know if you need any content of my files in /etc/yum.repos.d/ for debugging purpose. [root@schlebby /]# yum update Geladene Plugins: auto-update-debuginfo, presto, refresh-packagekit Found 12 installed debuginfo package(s) Enabling fedora-debuginfo: Fedora 13 - x86_64 - Debug Enabling rpmfusion-nonfree-debuginfo: RPM Fusion for Fedora 13 - Nonfree - Debug Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 13 - Free - Updates Debug Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 13 - Free - Debug Enabling updates-debuginfo: Fedora 13 - x86_64 - Updates - Debug Enabling rpmfusion-nonfree-updates-debuginfo: RPM Fusion for Fedora 13 - Nonfree - Updates Debug adobe-linux-i386 | 951 B 00:00 adobe-linux-i386/primary | 12 kB 00:00 adobe-linux-i386 18/18 fedora/metalink | 30 kB 00:00 fedora | 4.3 kB 00:00 fedora/primary_db | 13 MB 00:59 rpmfusion-free | 2.8 kB 00:00 rpmfusion-free/primary_db | 350 kB 00:01 rpmfusion-free-updates | 2.8 kB 00:00 rpmfusion-free-updates/primary_db | 230 kB 00:01 rpmfusion-free-updates-debuginfo | 2.3 kB 00:00 rpmfusion-nonfree | 2.8 kB 00:00 rpmfusion-nonfree/primary_db | 103 kB 00:00 rpmfusion-nonfree-updates | 2.8 kB 00:00 rpmfusion-nonfree-updates/primary_db | 38 kB 00:00 rpmfusion-nonfree-updates-debuginfo | 2.3 kB 00:00 rpmfusion-nonfree-updates-debuginfo/primary_db | 8.1 kB 00:00 updates/metalink | 25 kB 00:00 updates | 4.5 kB 00:00 updates/primary_db | 4.0 MB 00:18 updates-debuginfo/metalink | 17 kB 00:00 updates-debuginfo | 3.1 kB 00:00 updates-debuginfo/primary_db | 358 kB 00:01 virtualbox | 951 B 00:00 virtualbox/primary | 2.6 kB 00:00 virtualbox 6/6 Einrichten des Aktualisierungsprozess Keine Pakete für die Aktualisierung markiert
Yes we want more of a polling then to freeze the process. Fixed in setroubleshoot-2.2.93-1
/me wonders where the source of setroubleshoot-2.2.93-1 comes from - there is apparently no such fix in http://hg.fedorahosted.org/hg/setroubleshoot/
(In reply to comment #31) Mads, the source seems to be on koji with updated ChangeLog ... http://koji.fedoraproject.org/koji/buildinfo?buildID=190273 Oh yes, but the patch is missing in the source control. Outch! The update mirrors seem to still miss the new packages also. Last but not least, the packages on koji are not signed. I wanted to test them.
(In reply to comment #32) > The update mirrors seem to still miss the new packages also. > > Last but not least, the packages on koji are not signed. I wanted to test them. Yes, that is as expected. Koji is for building, not for pushing and not for signing.
This bug seems fixed on koji. Thanks. setroubleshoot-2.2.93-1.fc13.x86_64 setroubleshoot-server-2.2.93-1.fc13.x86_64
setroubleshoot-2.2.93-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/setroubleshoot-2.2.93-1.fc13
setroubleshoot-2.2.93-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/setroubleshoot-2.2.93-1.fc14
Jeepers, you try to do something on the Sunday of your Vacation... Everything should be updated.
Please update karma if this fixes your problem or everything works well.
setroubleshoot-2.2.93-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update setroubleshoot'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/setroubleshoot-2.2.93-1.fc14
setroubleshoot-2.2.93-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
setroubleshoot-2.2.95-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/setroubleshoot-2.2.95-1.fc14
setroubleshoot-2.2.98-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/setroubleshoot-2.2.98-1.fc14
oops wrong bug.
setroubleshoot-2.2.99-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/setroubleshoot-2.2.99-1.fc14
setroubleshoot-2.2.99-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.