Re: Unexpected gdbus behaviour during PAM authentication

On 13/01/17 15:47, Bastien Nocera wrote:
> On Fri, 2017-01-13 at 14:37 +0000, David Llewellyn-Jones wrote:
>> Hi all,
>>
>> I've been experiencing strange behaviour connecting to the system bus
>> from a pam module. This is on Ubuntu 16.04 using gdbus and gdbus-
>> codegen
>> for both the caller and listening service.
>>
>> Using a simple test application for thee caller everything works
>> fine.
>> Here's the minimal code for the test app and service:
>> https://github.com/llewelld/dbus-pam-test/blob/master/src/test.c
>> https://github.com/llewelld/dbus-pam-test/blob/master/src/service.c
>>
>> However, when I move the same code from the test program to a pam
>> module
>> I then get the unexpected behaviour. The pam module is executed by
>> pressing Win-L to trigger the Unity lock screen.
>>
>> The first time the pam module is run, it calls
>> *_proxy_new_for_bus_sync
>> to return a proxy and then calls the service and everything works
>> fine.
>> The second time it's run the same *_proxy_new_for_bus_sync function
>> returns a NULL proxy, but apparently without returning any error. The
>> third time it's run the *_proxy_new_for_bus_sync function hangs and
>> never returns.
>>
>> Here's the code for the pam module:
>> https://github.com/llewelld/dbus-pam-test/blob/master/src/pam_test.c
>>
>> This behaviour happens when I use the pam module with the unity lock
>> screen, but if I use pamtester instead, everything works fine every
>> time.
>>
>> And in case it's helpful, the output to syslog from running the
>> service
>> and pam module can be seen here:
>> https://github.com/llewelld/dbus-pam-test/blob/master/log-output.log
>>
>> Does anyone have any suggestion for why this might be happening?
> 
> GDBus's threads and PAM really don't mix. You'll need to either use
> something like dbus-glib, which is single-threaded and sync, move your
> D-Bus code to a small helper you'd talk to over Unix sockets (yeah, I
> know...), or wait until PAM dies.
> 
> FWIW, this problem is one of the reasons why fprintd (and pam_fprintd)
> is written using dbus-glib rather than GDBus.

Thanks for the feedback, that's really helpful to know. I'd explicitly
avoided dbus-glib because I thought it was deprecated, but it looks like
I should go back and give it a go.

Sadly waiting for PAM to die isn't an option ;)

David
-- 
Website: http://www.flypig.co.uk
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus