Description of problem: When selinux is disabled in /etc/selinux/config, the setroubleshoot GUI quits without explanation. Version-Release number of selected component (if applicable): setroubleshoot-2.2.64-1.fc13.i686 setroubleshoot-server-2.2.64-1.fc13.i686 setroubleshoot-plugins-2.1.40-1.fc13.noarch Fresh F13 install with updates. How reproducible: Always. Steps to Reproduce: 1. Disable selinux in /etc/selinux/config 2. Restart. 3. Select Applications:System Tools:SELinux Troubleshooter Actual results: The app. appears to be starting in the panel & pointer is a spinner, but quits after several seconds. Expected results: The app. displays an alert saying that selinux is disabled. Additional info: [stephent@pine selinux]$ cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. #SELINUX=enforcing SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted From /var/log/messages: Feb 25 14:26:22 pine setroubleshoot: [dbus.ERROR] could not start dbus: 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. Feb 25 14:27:57 pine setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.TimedOut: Activation of org.fedoraproject.Setroubleshootd timed out
Oh yes, please pop up a message or show _something_ telling what is going on, instead of leaving traces that indicates a serious error.
I can't imagine why anyone would ever disable SELinux :^) Fixed in setroubleshoot-2.2.95-1.fc13
seapplet will now write Applet requires SELinux be enabled to run. In .xsession-errors and error out.
setroubleshoot-2.2.95-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/setroubleshoot-2.2.95-1.fc13
(In reply to comment #2) > I can't imagine why anyone would ever disable SELinux :^) (As hinted in bug 624223 it wasn't my intention and "I didn't do it". I just want to help the next poor guy who ends up in that unfortunate situation. ;-) ) (In reply to comment #3) > seapplet will now write > Applet requires SELinux be enabled to run. > In .xsession-errors and error out. That could be nice. But only the expert user will notice that. From the description it seems like the user launching "troubleshooter" from the menu will get a bad experience. Please consider showing some kind of "SElinux not enabled" message box from /usr/bin/sealert -b.
Fixed in setroubleshoot-2.2.96-1.fc13
setroubleshoot-2.2.95-1.fc13 has been pushed to the Fedora 13 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: https://admin.fedoraproject.org/updates/setroubleshoot-2.2.95-1.fc13
setroubleshoot-2.2.96-1.fc13 has been pushed to the Fedora 13 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: https://admin.fedoraproject.org/updates/setroubleshoot-2.2.96-1.fc13
setroubleshoot-2.2.96-1.fc13.x86_64 retest: When selinux is disabled, "sealert -b" now displays an alert saying: "SELinux not enabled, sealert will not run on non SELinux systems" and offers a "Close" button. After clicking the "Close" button, there is a slight delay before sealert exits. Unfortunately, dbus-daemon begins consuming nearly 100% CPU for about a minute. After starting sealert again, it hangs for about 10 seconds before displaying the alert. The message refers to "sealert", which is not meaningful to GUI users: "SELinux Troubleshooter has detected that SELinux is not enabled. Please enable SELinux before using this application." Test procedure: [stephent@walnut ~]$ sestatus SELinux status: disabled [stephent@walnut ~]$ sealert -b [Click Close button]
(In reply to comment #9) > Unfortunately, dbus-daemon begins consuming nearly 100% CPU for about a > minute. strace shows dbus-daemon is repeatedly and rapidly calling poll(). poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=25, events=POLLIN}, {fd=27, events=POLLIN}, {fd=28, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=35, events=POLLIN}, {fd=26, events=POLLIN}, {fd=38, events=POLLIN}, {fd=24, events=POLLIN}, {fd=36, events=POLLIN}, {fd=37, events=POLLIN}, ...], 66, 3305) = 2 ([...])
There are several messages like this in /var/log/messages: Sep 6 06:59:25 localhost setroubleshoot: [dbus.ERROR] could not start dbus: 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.
(I filed bug 630660 which is related.) (In reply to comment #9) > The message refers to "sealert", which is not meaningful to GUI users: The different modes of "sealert" is quite confusing for the user. It is called "SELinux Troubleshooter" in the menu, and it calls itself "SELinux Troubleshoot Browser". I have often been confused by the process name "sealert" which didn't associate to the SE troubleshoot browser. "setroubleshootd" sounds more like the troubleshoot browser ... but it isn't. It is also hard to find out how to launch "the selinux troubleshoot browser" from the command line. It could be nice if the gui browser was split out in a separate command (and its own package) - for example setroubleshootbrowser or just sebrowser. (Unless the gui is replaced by a mode in abrt...)
(In reply to comment #12) > (I filed bug 630660 which is related.) > > > (In reply to comment #9) > > The message refers to "sealert", which is not meaningful to GUI users: > > The different modes of "sealert" is quite confusing for the user. > > It is called "SELinux Troubleshooter" in the menu, and it calls itself "SELinux > Troubleshoot Browser". I have often been confused by the process name "sealert" > which didn't associate to the SE troubleshoot browser. "setroubleshootd" sounds > more like the troubleshoot browser ... but it isn't. > > It is also hard to find out how to launch "the selinux troubleshoot browser" > from the command line. > > It could be nice if the gui browser was split out in a separate command (and > its own package) - for example setroubleshootbrowser or just sebrowser. (Unless > the gui is replaced by a mode in abrt...) Soft links to sealert could solve some of these problems: setroubleshoot -> sealert This would invoke sealert in browser mode. Compare: [stephent@walnut ~]$ ls -lF /usr/bin/ex lrwxrwxrwx. 1 root root 3 Jul 22 08:13 /usr/bin/ex -> vim* Or busybox ... BTW, here's a way to find the command line for a GUI app: [stephent@walnut ~]$ rpm -ql setroubleshoot | grep desktop /etc/xdg/autostart/sealertauto.desktop /usr/share/applications/setroubleshoot.desktop [stephent@walnut ~]$ grep Exec /usr/share/applications/setroubleshoot.desktop Exec=/usr/bin/sealert -b (Nautilus really ought to support this, though.)
Send me patches please.
setroubleshoot-2.2.96-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #9) > ... > Unfortunately, dbus-daemon begins consuming nearly 100% CPU for about a > minute. Bug 633496 - dbus-daemon may consume 100% CPU