Description of problem: If you are non-root and you run sealert to report on a problem tha occurred for a root process and you are in a graphical environment then you get a popup dialog with a DBus exception (and you have to cliick it away) The message in the dialog box is Traceback (most recent call last): File "/usr/bin/sealert", line 1006, 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.6120" (uid=500 pid=16130 comm="/usr/bin/python) interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.6121" (uid=0 pid=16132 comm="/usr/bin/python)) Version-Release number of selected component (if applicable): $ rpm -q -f /usr/bin/sealert setroubleshoot-server-2.2.102-1.fc14.i686 How reproducible: very Steps to Reproduce: 0. ssh -Y -A faraway.example.com gnome-terminal focus on that new gnome-terminal that pops up 1. [on faraway.example.com] find some sealert messages that occurred as root I used the ones reported here https://bugzilla.redhat.com/show_bug.cgi?id=661550 2. [on faraway.example.com] see the codes in /var/log/messages 3. [on faraway.example.com] without becoming root (i.e. as yourself), try to exhibit the reports. To wit: $ cat s.list 0a322d86-d3bb-4c04-9c38-ed5602bbfceb 3d11616d-3017-4290-bf7a-9cb89203f25b 0600b596-fb02-404f-a2db-3fd14f3a460f 0600b596-fb02-404f-a2db-3fd14f3a460f 156040f2-2c73-4506-814a-b2f689e205a8 [fails] $ for i in $(< s.list ) ; do echo $i -------------- ; sealert -l $i; done [succeeds] $ for i in $(< s.list ) ; do echo $i -------------- ; sudo sealert -l $i; done The point is that you have to be root to see root problems. Actual results: The above-mentioned GUI modal dialog box that you have to click away to proceed. Expected results: There are two opportunities here a) just fail out directly and give a textual exception message (it was a textual query); i.e. no modal gui dialog interaction b) catch the exception and ask for escalated privileges (this is hard, so why bother?) Additional info:
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.