Bug 214218 - no sealert applet on AVC deny
no sealert applet on AVC deny
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
Ben Levenson
:
: 215135 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 12:34 EST by Thorsten Scherf
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-28 01:15:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thorsten Scherf 2006-11-06 12:34:36 EST
Description of problem:
sealert doesn't start up. 

Version-Release number of selected component (if applicable):
setroubleshoot-1.0-1

How reproducible:
create an AVC deny 

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
there is only a log entry, but not sealert message pops up on the desktop

Expected results:
popup on the desktop


Additional info:
/var/log/messages:
Nov  6 18:13:40 tiffy setroubleshoot:      SELinux is preventing the
/usr/sbin/httpd from using potentially mislabeled files (/var/www/html/test).  
   See audit.log for complete SELinux messages. id =
671f8958-3e13-4d74-ad63-752534e0d955
Nov  6 18:14:38 tiffy setroubleshoot: 2006-11-06 18:14:38,013 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)
Nov  6 18:14:43 tiffy setroubleshoot: 2006-11-06 18:14:43,698 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)
Nov  6 18:14:56 tiffy setroubleshoot: 2006-11-06 18:14:56,146 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)

installes with latest fc6 rpms.
Comment 1 John Dennis 2006-11-06 13:10:52 EST
This is usually a symptom of the session bus either not running, or not bound to
your session. It's not a setroubleshoot issue.

For starters, is DBUS_SESSION_BUS_ADDRESS defined in your environment? (e.g. set
| grep DBUS_SESSION).

When happens when you run dbus-monitor? Do you get the same you list above?

Did you ssh in thus bypassing the dbus-launch gdm performs for you?

Provided you have a DBUS_SESSION_BUS_ADDRESS defined then what does 'ps ax |
grep dbus' show? Do you have a daemon listed after the dbus-launch? Is it
running? What happens if you close your session and log back in? Does the
problem go away?

Anyway, this isn't a setroubleshoot issue per se, it's more to do with dbus or
how you're trying to run things.
Comment 2 Thorsten Scherf 2006-11-06 17:37:15 EST
as discussed on irc, when calling sealert it just dies:

[tscherf@tiffy ~]$ sealert -s

(Setroubleshoot-Browser:5423): libglade-CRITICAL **: glade_xml_build_interface:
assertion `wid != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/sealert", line 426, in ?
    start_service()
  File "/usr/bin/sealert", line 376, in start_service
    app.main()    
  File "/usr/bin/sealert", line 350, in main
    self.browser = BrowserApplet()
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 79, in
__init__
    self.init_widgets()
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 104,
in init_widgets
    self.window.connect_after("realize", self.on_realize)
AttributeError: 'NoneType' object has no attribute 'connect_after'

rpm -V setroubleshoot|grep glade shows no problem with the glade files.
Comment 3 Thorsten Scherf 2006-11-06 17:44:24 EST
problem remains with setroubleshoot rawhide version 1.3-1
 
Comment 4 John Dennis 2006-11-07 13:29:16 EST
Thorsten, I would like to do one more diagnostic test for me please. This
morning I discovered many of the system-config-* applets will not run, they seem
to fail because they can't open the X display. The tracebase in comment #2 is
saying there is no window, the inability to open the display is a very likely
candidate for why there is no window. 

For the failing console helper apps if I monitor /var/log/Xorg.0.log (tail -f)
I'll see message like this:

AUDIT: Tue Nov  7 13:11:18 2006: 2241 Xorg: client 31 rejected from local host

and what the client sees is a failure to open the X windows display and the
inability to open any windows.

Could you please see if you're getting these messages in your
/var/log/Xorg.0.log file? Try running system-config-soundcard, that's one which
I know fails for me. Try it with sealert -s on the command line and invoked from
the System->Administration->setroubleshoot menu item. Are the client rejection
messages generated in the X log when you do these things?
Comment 5 Thorsten Scherf 2006-11-08 04:51:09 EST
there is no log entry as you described. sorry. I really guess it has something
to do with dbus. we could try to isolate the problem later on, will be available
around 2pm EST, if you would like access one of the machines where this bug
happened...
Comment 6 Alphonse Van Assche 2006-11-09 18:35:21 EST
Apparently, i have the same bug, some strings which should not be i18l, should
be, i have found one in browser.py.

-        self.window_name = _('browser')
+        self.window_name = "browser"

There are other files to patch, because the notification is show but the icon is
not.
 
When I start gnome in English all work perfectly.

ps: the same log output as Thorsten about dbus.


Comment 7 John Dennis 2006-11-09 22:21:20 EST
Good catch Alphonse! That would certainly explain things, thank you for your
help in diagnosing the problem. I never occurred to me to consider i18n as a
root cause.

However, I think this line:

self.window_name = _('browser')

is correct, that the name displayed to the user and it should be i18n, but the
mistake was then using this name to look up the widget in the glade file, here:

        self.window = self.wTree.get_widget(self.window_name)

that name should be hard coded to match the name in the glade file.

Thorsten, does running in english or modifying either of the two lines
referenced in /usr/lib/python2.4/site-packages/browser.py to be 'browser' fix
the problem for you? The i18n component probably explains why the problem you
were reporting wasn't surfacing more often and why we were not seeing it.
Comment 8 John Dennis 2006-11-09 22:24:09 EST
Oh, by the way, along with fixing the i18n issue, we'll also fix the error
checking/reporting, the dbus failure was a red herring caused by a chain of
earlier events.
Comment 9 Thorsten Scherf 2006-11-10 02:53:20 EST
Very good catch.

When changing  self.window_name = _("browser") to  self.window_name =
("browser") it works without problems.
Comment 10 Alphonse Van Assche 2006-11-11 07:01:46 EST
cf: There are other files to patch, because the notification is show but the
icon is not.

Oups, self.window_name = "browser" fix entirely the problem for me too (after a
reboot)
Comment 11 John Dennis 2006-11-11 08:29:37 EST
*** Bug 215135 has been marked as a duplicate of this bug. ***

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