Re: Unexpected gdbus behaviour during PAM authentication

Bastien Nocera <[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <[email protected]>
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
:)
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.