Bug 663854 - DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules;
Summary: DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 14
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-17 03:30 UTC by Wendell Baker
Modified: 2011-01-15 22:23 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-01-15 22:23:44 UTC


Attachments (Terms of Use)
Actuality of the continuing failure behavior with setroubleshoot-3.0.15-1.fc14.i686 (123.65 KB, image/png)
2010-12-18 17:57 UTC, Wendell Baker
no flags Details
actuality of yum install from updates for setroubleshoot-3.0.15-1.fc14.i686 (4.42 KB, text/plain)
2010-12-18 17:59 UTC, Wendell Baker
no flags 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 (152.36 KB, image/png)
2010-12-22 15:05 UTC, Wendell Baker
no flags Details

Description Wendell Baker 2010-12-17 03:30:33 UTC
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:

Comment 1 Daniel Walsh 2010-12-17 14:31:44 UTC
Please try the new setroubleshoot available in updates-testing.

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

Fixed in setroubleshoot-3.0.15-1.fc14

Comment 2 Wendell Baker 2010-12-18 17:57:51 UTC
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@nineteen.emerson.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.

Comment 3 Wendell Baker 2010-12-18 17:59:46 UTC
Created attachment 469527 [details]
actuality of yum install from updates for setroubleshoot-3.0.15-1.fc14.i686

Comment 4 Daniel Walsh 2010-12-20 21:16:21 UTC
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.

Comment 5 Daniel Walsh 2010-12-22 14:12:30 UTC
Wendell did it start working after reboot?

Comment 6 Wendell Baker 2010-12-22 14:49:46 UTC
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@nineteen.emerson.baker.org]
$ sealert -l 0600b596-fb02-404f-a2db-3fd14f3a460f

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

[as wbaker:wbaker@nineteen.emerson.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@nineteen.emerson.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

Comment 7 Wendell Baker 2010-12-22 15:01:35 UTC
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.

Comment 8 Wendell Baker 2010-12-22 15:05:00 UTC
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

Comment 9 Daniel Walsh 2010-12-22 18:02:57 UTC
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.

Comment 10 Wendell Baker 2010-12-22 20:02:33 UTC
> 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.

Comment 11 Daniel Walsh 2010-12-22 20:11:46 UTC
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.

Comment 12 Daniel Walsh 2011-01-06 21:14:04 UTC
Fixed in setroubleshoot-3.0.19-1.fc14

Comment 13 Fedora Update System 2011-01-06 21:15:15 UTC
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

Comment 14 Fedora Update System 2011-01-07 19:57:24 UTC
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

Comment 15 Fedora Update System 2011-01-15 22:23:39 UTC
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.


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