Bug 568541 - setroubleshoot GUI quits without explanation when selinux disabled
Summary: setroubleshoot GUI quits without explanation when selinux disabled
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Thomas Liu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-25 23:02 UTC by Steve Tyler
Modified: 2010-09-13 20:37 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-09-09 01:12:50 UTC


Attachments (Terms of Use)

Description Steve Tyler 2010-02-25 23:02:36 UTC
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

Comment 1 Mads Kiilerich 2010-08-14 19:07:11 UTC
Oh yes, please pop up a message or show _something_ telling what is going on, instead of leaving traces that indicates a serious error.

Comment 2 Daniel Walsh 2010-08-26 11:47:50 UTC
I can't imagine why anyone would ever disable SELinux :^)

Fixed in setroubleshoot-2.2.95-1.fc13

Comment 3 Daniel Walsh 2010-08-26 11:50:08 UTC
seapplet will now write

Applet requires SELinux be enabled to run.

In .xsession-errors and error out.

Comment 4 Fedora Update System 2010-08-26 12:28:10 UTC
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

Comment 5 Mads Kiilerich 2010-08-26 12:29:25 UTC
(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.

Comment 6 Daniel Walsh 2010-08-26 18:07:40 UTC
Fixed in setroubleshoot-2.2.96-1.fc13

Comment 7 Fedora Update System 2010-08-27 06:49:53 UTC
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

Comment 8 Fedora Update System 2010-09-01 03:27:11 UTC
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

Comment 9 Steve Tyler 2010-09-06 13:55:36 UTC
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]

Comment 10 Steve Tyler 2010-09-06 14:05:03 UTC
(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 ([...])

Comment 11 Steve Tyler 2010-09-06 14:09:34 UTC
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.

Comment 12 Mads Kiilerich 2010-09-06 15:33:50 UTC
(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...)

Comment 13 Steve Tyler 2010-09-06 17:35:26 UTC
(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.)

Comment 14 Daniel Walsh 2010-09-07 19:09:57 UTC
Send me patches please.

Comment 15 Fedora Update System 2010-09-09 01:12:45 UTC
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.

Comment 16 Steve Tyler 2010-09-13 20:37:11 UTC
(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


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