Client should notify the user if the user lacks permission to use it

Bug #333867 reported by Robby Workman
2
Affects Status Importance Assigned to Milestone
wicd
Fix Released
Medium
Andrew Psaltis

Bug Description

If wicd's dbus configuration file is set up to allow only users that belong to a specific group to actually use wicd, then the client should have some way of telling users that they can't use it. To be clear, what happens currently is this:

On login, even though the tray icon is set to run on startup, it does not, and there's absolutely no kind of notification about *why* it didn't start. Click the wicd icon in the desktop menu, and absolutely nothing happens. Nothing.
If I start the client from a terminal, here's the traceback:

$ wicd-client
Loading...
Connecting to daemon...
Connected.
warning: ignoring exception org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.103" (uid=1002 pid=10237 comm="python -O /usr/lib/wicd/wicd-client.py ") interface="org.wicd.daemon" member="GetConnectionStatus" error name="(unset)" requested_reply=0 destination=":1.7" (uid=0 pid=25543 comm="python -O /usr/lib/wicd/wicd-daemon.py "))
Traceback (most recent call last):
  File "/usr/lib/wicd/wicd-client.py", line 780, in <module>
    main(sys.argv)
  File "/usr/lib/wicd/wicd-client.py", line 757, in main
    if DBUS_AVAIL and daemon.GetNeedWiredProfileChooser():
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 622, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.103" (uid=1002 pid=10237 comm="python -O /usr/lib/wicd/wicd-client.py ") interface="org.wicd.daemon" member="GetNeedWiredProfileChooser" error name="(unset)" requested_reply=0 destination=":1.7" (uid=0 pid=25543 comm="python -O /usr/lib/wicd/wicd-daemon.py "))

If I start the curses client, here's what happens:

$ wicd-curses
Traceback (most recent call last):
  File "/usr/lib/wicd/wicd-curses.py", line 954, in <module>
    parser = OptionParser(version="wicd-curses-%s (using wicd %s)" % (CURSES_REVNO,daemon.Hello()))
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 622, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.99" (uid=1002 pid=10104 comm="python -O /usr/lib/wicd/wicd-curses.py ") interface="org.wicd.daemon" member="Hello" error name="(unset)" requested_reply=0 destination=":1.7" (uid=0 pid=25543 comm="python -O /usr/lib/wicd/wicd-daemon.py "))

I don't know what the best way to handle this is, so discussion is welcome - I just think that we should do *something* besides nothing. :-)

Tags: 1.6.0

Related branches

Revision history for this message
Andrew Psaltis (nacl) wrote :

In the curses client, that is literally the first thing called after DBus is initialized. So, I could wrap that in a try/except block and print out an error message if that the user were not "allowed" to use wicd.

Revision history for this message
Dan O'Reilly (oreilldf) wrote :

I'll just have to change the decorator we use to catch DBusExceptions to throw up an error dialog if we get an access denied error.

Changed in wicd:
assignee: nobody → oreilldf
status: New → Triaged
Changed in wicd:
milestone: none → 1.6-testing-release
Dan O'Reilly (oreilldf)
Changed in wicd:
importance: Undecided → Medium
Andrew Psaltis (nacl)
Changed in wicd:
milestone: 1.6-alpha → 1.6.1-release
Revision history for this message
Andrew Psaltis (nacl) wrote :

I have a branch set up at lp:~nacl/wicd/1.6-access-denied which resolves this problem, currently pending a merge.

Changed in wicd:
assignee: Dan O'Reilly (oreilldf) → Andrew Psaltis (nacl)
status: Triaged → In Progress
Revision history for this message
Andrew Psaltis (nacl) wrote :

Fix released in 1.6.1.

Changed in wicd:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.