Seems ObtainAuthorization was not called. This PolicyKit method usually is invoked via RemoteControlProperties._unlock(). Are there any error messages when running g-l-p?

That's the full log of gnome-lirc-properties with -d:
INFO:root:Reading remote database from /usr/share/lirc-remotes/...
WARNING:root:/usr/share/lirc-remotes/: Remote Apple_A1156 listed twice in apple/lircd.conf.macmini and apple/lircd.conf.macmini.
WARNING:root:/usr/share/lirc-remotes/: Remote DVICO_MCE listed twice in dvico/lircd.conf.fusionHDTV and dvico/lircd.conf.fusionHDTV.
WARNING:root:/usr/share/lirc-remotes/: Remote Medion_X10 listed twice in atiusb/lircd.conf.atiusb and atiusb/lircd.conf.atiusb.
WARNING:root:/usr/share/lirc-remotes/: Remote Medion_X10 listed twice in atiusb/lircd.conf.atiusb and atiusb/lircd.conf.atiusb.
WARNING:root:/usr/share/lirc-remotes/: Remote BESTBUY listed twice in bestbuy/lircd.conf.bestbuy2 and bestbuy/lircd.conf.bestbuy.
WARNING:root:/usr/share/lirc-remotes/: Remote NEC listed twice in generic/NEC-short-pulse.conf and generic/NEC-pulse.conf.
WARNING:root:/usr/share/lirc-remotes/: Remote NEC listed twice in generic/NEC.conf and generic/NEC-pulse.conf.
WARNING:root:/usr/share/lirc-remotes/: Remote SONY listed twice in generic/SONY20.conf and generic/SONY12.conf.
WARNING:root:/usr/share/lirc-remotes/: Remote PVR2000 listed twice in leadtek/lircd.conf.PVR2000 and leadtek/lircd.conf.PVR2000.
DEBUG:root:org.gnome.lirc-properties.mechanism.configure: authorized=dbus.String(u'auth_self_keep_always')
INFO:root:trying to connect to lircd...
INFO:root:disconnecting source: 37
INFO:root:closing socket: 7
INFO:root:0/13: Belkin Components F5D7050A Wireless Adapter
INFO:root:1/13: Macpower Peripherals, Ltd MINIMAX
INFO:root:2/13: Genesys Logic, Inc. USB-2.0 4-Port HUB
INFO:root:3/13: Standard Microsystems Corp. USB 2.0 Hub
INFO:root:4/13: Linux Foundation 2.0 root hub
INFO:root:5/13: Logitech, Inc. MX5000 Cordless Desktop
INFO:root:6/13: Logitech, Inc. MX1000 Bluetooth Laser Mouse
INFO:root:7/13: Logitech, Inc. BT Mini-Receiver (HID proxy mode)
INFO:root:8/13: Linux Foundation 1.1 root hub
INFO:root:9/13: Linux Foundation 1.1 root hub
INFO:root:10/13: Linux Foundation 1.1 root hub
INFO:root:11/13: Linux Foundation 1.1 root hub
INFO:root:12/13: Logitech Logitech BT Mini-Receiver
DEBUG:root:Access denied, reauthenticating: DBusException('Traceback (most recent call last):\n  File "/usr/lib/python2.5/site-packages/dbus/service.py", line 696, in _message_cb\n    retval = candidate_method(self, *args, **keywords)\n  File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/backend.py", line 744, in ManageLircDaemon\n    self._check_permission(sender)\n  File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/backend.py", line 73, in _check_permission\n    raise AccessDeniedException(\'Process not authorized by PolicyKit\')\nAccessDeniedException: org.gnome.LircProperties.AccessDeniedException: Process not authorized by PolicyKit\n',)
DEBUG:root:org.gnome.lirc-properties.mechanism.configure: authorized=dbus.String(u'auth_self_keep_always')
INFO:root:Authorized already. No need to obtain authorization.
[...]

What do you do to trigger this? Does it happen just by clicking the Unlock button? Everything is grayed-out at startup otherwise, right?

Created attachment 113702 [details] [review]
Check output of is_authorized properly

The result of policykit.PolicyKitAuthentication.is_authorized() is a string representing the textual value from PolKitResult, not a boolean...

There's still some problems with the patch above though. There might be some other incorrect uses. Checking now.

I think there may have been a change in PolicyKit, because this worked on Ubuntu. But PolicyKit is not properly documented.

I guess Fedora 9 is likely to have a newer PolicyKit than Ubuntu Hardy so this is OK, and we'll found out later if it's not. It's not a risk for Ubuntu Hardy because they are very unlikely to take a new version of g-l-p before Ubuntu Intrepid. 

Never mind, that's crap. I didn't see it was from a helper function.

I believe that's the problem, in the backend:
                pid = dbus.UInt32(os.getpid())•
•
                granted = kit.IsProcessAuthorized(action, pid, False)•
                logging.info('process authorization: %r', granted)•
•
                if 'no' == granted:•
                    raise AccessDeniedException('Process not authorized by PolicyKit')•

It's checking if the backend's PID itself is authorised, not whether the sender's PID is.

And that bug still being in my PolicyKit packages won't help either:
http://gitweb.freedesktop.org/?p=PolicyKit.git;a=commitdiff;h=15ae6e6acea3b1d1085d214294465fafc45af54b

So, the portion of code from comment 8 needs to be removed, and you need to make sure your version of PolicyKit has the patch from comment 9 (PolicyKit 0.8 only).

OK to remove the chunk of code from above?

Created attachment 113711 [details] [review]
patch to fix the above problem

Thanks.

Is that in a released version of PolicyKit yet? If this patch depends on the change in PolicyKit then I'd rather wait for it to be in a PolicyKit release.

(In reply to comment #12)
> Thanks.
> 
> Is that in a released version of PolicyKit yet? If this patch depends on the
> change in PolicyKit then I'd rather wait for it to be in a PolicyKit release.

The PolicyKit fix is needed for every PolicyKit 0.8 installation, because autorization reads are locked down so no one but the original user can read it. Locking out root is an oversight.

As for the patch, I don't understand how it could have worked before, checking its own PID for authorization when it clearly didn't ask for one.

But is that in a released version of PolicyKit yet?

No, but it doesn't matter because the code in gnome-lirc-properties is broken.

Yes, it is not so simple. But I wanted to know. Thanks.

There's obviously something we don't know here, because it does work in Ubuntu Hardy. Maybe they patch it, though the git commit seems too new for that, and it's surprising to me that PolicyKit could be so totally broken while deployed widely in Ubuntu Hardy and Fedora Core 9.

But anyway, even if this would break Ubuntu Hardy, that's no great risk because they are unlikely to take a new version anyway, and we can check it if they do.

So, please commit, and thanks for the explanations.

However, could you please just comment out that current code, and add some comments to explain what it did (wrong) and what you now do right. PolicyKit is so undocumented that we need comments to document it in our own code.

(In reply to comment #16)
> Yes, it is not so simple. But I wanted to know. Thanks.
> 
> There's obviously something we don't know here, because it does work in Ubuntu
> Hardy. Maybe they patch it, though the git commit seems too new for that, and
> it's surprising to me that PolicyKit could be so totally broken while deployed
> widely in Ubuntu Hardy and Fedora Core 9.

It's only broken when using the D-Bus method, so that might explain why only few people hit that problem.

> But anyway, even if this would break Ubuntu Hardy, that's no great risk because
> they are unlikely to take a new version anyway, and we can check it if they do.
> 
> So, please commit, and thanks for the explanations.
> 
> However, could you please just comment out that current code, and add some
> comments to explain what it did (wrong) and what you now do right. PolicyKit is
> so undocumented that we need comments to document it in our own code.

Will do.

I just re-read that, and there's nothing to really documented. Checking the helper's PID for authorization should never have worked. We don't have access to the caller's PID, so we rely on the sender's dbus name to check for authorization.

The PolicyKit bug is just the reason why the code still wasn't working on my system once we removed the PID checks.

> Checking the helper's PID for authorization should never have worked. We don't > have access to the caller's PID, so we rely on the sender's dbus name to check > for authorization.

I'd like to see at least a sentence like that as a comment in the code.

I'm more obsessed with comments than most people, but humor me.

(In reply to comment #14)
> But is that in a released version of PolicyKit yet?

I'm planning to do a 0.9 release very soon; see

http://lists.freedesktop.org/archives/polkit-devel/2008-June/000002.html

it's going to be mostly bug fixes. As you can see we also have a mailing list now; I think you or someone else asked for that earlier.

There, with a big lump of comment :)

I also removed the "pid = ..." line, as we surely don't need it anymore.

2008-07-01  Bastien Nocera  <hadess@hadess.net>

	* gnome_lirc_properties/backend.py: Remove authorization check
	by PID (IsProcessAuthorized) because we were checking the
	backend's PID, which is surely not authorized, and we have
	no way to get to the front-end's PID. Just check with the
	sender's D-Bus name instead (Closes: #540912)