Unexpected gdbus behaviour during PAM authentication

[Bastien Nocera]

On Fri, 2017-01-13 at 15:53 +0000, David Llewellyn-Jones wrote:
> 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_tes
> > > t.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.

There's also the option of libdbus, with or without a wrapper like
bluez' "gdbus" (yeah, I know as well...), or systemd's sd-bus.

If anyone has knowledge opinions or experience using sd-bus in separate
applications (eg. system daemons), I'd be happy to hear.

dbus-glib is a wrapper for libdbus, so it would really be moving
sideways for fprintd.

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

It was on the cards at some point, I wish the replacement would appear
:)