Bug 663854

Please try the new setroubleshoot available in updates-testing.

yum -y update setroubleshoot\* -enablerepo=updates-testing

Fixed in setroubleshoot-3.0.15-1.fc14

Created attachment 469526 [details]
Actuality of the continuing failure behavior with setroubleshoot-3.0.15-1.fc14.i686

Do I have the right stuff installed?

$ rpm -q -a | grep setrouble
setroubleshoot-plugins-3.0.8-1.fc14.noarch
setroubleshoot-server-3.0.15-1.fc14.i686
setroubleshoot-3.0.15-1.fc14.i686

I include the yum output separately

Actuality of the continuing behavior is attached above

[on localhost]
$ ssh -Y -A wbaker.baker.org gnome-terminal

In the screenshot:
The gnome terminal is that blue-gray colored stuff in the background.
The sealert popup occurs on my local machine

[on nineteen]
$ ps -ef | grep python
wbaker   16193 13777  0 08:37 pts/5    00:00:05 /usr/bin/python -Es /usr/bin/sealert -l 0600b596-fb02-404f-a2db-3fd14f3a460f



To force text mode (this is a fully textual application, no?) one needs to do this:


[on nineteen]
$ echo $DISPLAY
localhost:10.0
$ DISPLAY= sealert -l 0600b596-fb02-404f-a2db-3fd14f3a460f
Opps, sealert hit an error!

Traceback (most recent call last):
  File "/usr/bin/sealert", line 705, in <module>
    iface.start()
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.6677" (uid=500 pid=16840 comm="/usr/bin/python) interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.6678" (uid=0 pid=16842 comm="/usr/bin/python))




I think the desired behavior here is that sealert not pop up a dialog.

Created attachment 469527 [details]
actuality of yum install from updates for setroubleshoot-3.0.15-1.fc14.i686

That looks fine.  The thing you attached above, I can not view.

You might have to reboot, and then regenerate the error you had earlier.

Wendell did it start working after reboot?

mime type fixed on a1.png.
was text/plain now image/png



It didn't.  I'm working on a longer answer ... to the reboot question.



I had rebooted.

All times PST ...

2010-12-17T11:18 installed the new setroubleshoot at 
2010-12-18T09:57 filed the report
2010-12-18T13:47 rebooted; kernel - downgrade (to acquire some iptables kmods)
2010-12-22T06:04 tested setroubleshoot again

see below for provenance


This morning ... retrying ...

[as wbaker:wbaker.baker.org]
$ sealert -l 0600b596-fb02-404f-a2db-3fd14f3a460f

[as wbaker:wbaker.baker.org]
$ uptime
 05:56:22 up 3 days, 16:09,  9 users,  load average: 0.82, 0.70, 0.58

[as wbaker:wbaker.baker.org]
$ last | grep 'boot'
reboot   system boot  2.6.35.6-45.fc14 Sat Dec 18 13:47 - 05:56 (3+16:09)   

[as wbaker:wbaker.baker.org]
$ sudo grep yum /var/log/messages-20101219 | tail | grep setrouble
Dec 16 18:19:11 nineteen yum[7830]: Updated: gnome-python2-libegg-2.25.3-26.fc14.1.i686
Dec 16 18:19:12 nineteen yum[7830]: Updated: gnome-python2-gtkhtml2-2.25.3-26.fc14.1.i686
Dec 16 18:19:13 nineteen yum[7830]: Updated: plymouth-gdm-hooks-0.8.4-0.20100823.7.fc14.i686
Dec 17 11:18:09 nineteen yum[3286]: Updated: setroubleshoot-plugins-3.0.8-1.fc14.noarch
Dec 17 11:18:19 nineteen yum[3286]: Updated: setroubleshoot-server-3.0.15-1.fc14.i686
Dec 17 11:18:32 nineteen yum[3286]: Updated: setroubleshoot-3.0.15-1.fc14.i686

Here's a chain of reasoning from reading /usr/bin/sealert ...
$ rpm -q -f /usr/bin/sealert
setroubleshoot-server-3.0.15-1.fc

Consider ...

$ sealert --debug -l 0600b596-fb02-404f-a2db-3fd14f3a460f
2010-12-22 06:32:27,014 [dbus.proxies.ERROR] Introspect error on :1.1392:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched rules; type="method_call", sender=":1.1396" (uid=500 pid=1395 comm="/usr/bin/python) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.1392" (uid=0 pid=1186 comm="/usr/bin/python))
2010-12-22 06:32:27,015 [dbus.proxies.DEBUG] Executing introspect queue due to error
2010-12-22 06:32:27,018 [program.ERROR] exception DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.1396" (uid=500 pid=1395 comm="/usr/bin/python) interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.1392" (uid=0 pid=1186 comm="/usr/bin/python))
Traceback (most recent call last):
  File "/usr/bin/sealert", line 705, in <module>
    iface.start()
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.1396" (uid=500 pid=1395 comm="/usr/bin/python) interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.1392" (uid=0 pid=1186 comm="/usr/bin/python))


The gui traceback says
Opps, sealert hit an error!

Traceback (most recent call last):
  File "/usr/bin/sealert", line 705, in <module>
    iface.start()
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.1396" (uid=500 pid=1395 comm="/usr/bin/python) interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.1392" (uid=0 pid=1186 comm="/usr/bin/python))

In /usr/bin/sealert, with invocation_style = 'lookupid' the core of the execution is

        elif invocation_style == 'lookupid':
            from setroubleshoot.signature import *
            try:
                # make sure setroubleshoot is running
                bus = dbus.SystemBus()
                proxy_obj = bus.get_object(dbus_system_bus_name, dbus_system_object_path)
                iface = dbus.Interface(proxy_obj, dbus_system_interface)
                iface.start()
                command_line_lookup_id(local_id)
                iface.finish()
            except ValueError, e:
                print >> sys.stderr, e
                sys.exit(3)

            sys.exit()


The exception is thrown out of iface.start(), the exception is a DBusException (/usr/lib/python2.7/site-packages/dbus/exceptions.py)
which is not a ValueError and thus the exception is caught by the outermost try/except

    except Exception, e:
        log_program.exception("exception %s: %s",e.__class__.__name__, str(e))
        display_traceback('sealert')
        sys.exit(3)

But we have earlier in /usr/bin/sealert ...

try:
    from setroubleshoot.gui_utils import display_traceback
except:
    def display_traceback(who):
        import traceback
        stacktrace = traceback.format_exc()
        print _("Opps, %s hit an error!" % who) + '\n\n' +stacktrace



Which basically says that if setroubleshoot.guiutils can provide display_traceback then use that, else splatter on stdout.  Thusly, any uncaught exception invocation_style == 'lookupid' is going to pop up GUI dialogs.

Created attachment 470212 [details]
For completeness ... 2010-12-22T05:08; nineteen.emerson.baker.org; sealert; bugzilla.redhat.com, 663854; sealert --debug; Screen shot of sealert DBus graphical display of exception handling

I am looking into the introspect error.  I think the other problem is you tried to start sealert on a machine that does not see you as being on the console.  So it is rejecting the reading of the database.

> I think the other problem is you tried to start sealert on a machine that does not see you as being on the console. So it is rejecting the reading of the database.

Agreed & expected.  My view here is that the only "surprise" is the exception handling by gtk issue, the other access level issue is an expected behavior.  

The behaviors that I think is correct & reasonable here are:

- To "see" a sealert report for a process that was root, you have to become root (again); thus one should have to sudo to see the reports we're discussing here as they pertain to sendmail and its allied processes (milter-greylist, etc.)
- If one runs a text-only process then text-only exception handling occurs (no surprise modal dialog boxes); no need to set DISPLAY= to ensure an interactive experience doesn't occur.

This test should pass...

sudo test 1
if ! sealert -l $code ; then
    if ! sudo sealert -l $code ; then
        echo "does report $code even exist?"
    fi
fi
echo DONE

If there is no gtk modal dialog popup then the codefrag above always executes to completion; either it exhibits the report or it gives a pithy error message.

That part I have fixed in 

setroubleshoot-3.0.16-1.fc15

I will backport as soon as I figure out what is going on with the introspection failing.

Fixed in setroubleshoot-3.0.19-1.fc14

setroubleshoot-3.0.19-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/setroubleshoot-3.0.19-1.fc14

setroubleshoot-3.0.19-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: https://admin.fedoraproject.org/updates/setroubleshoot-3.0.19-1.fc14

setroubleshoot-3.0.19-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.