PAM testing using pam_wrapper and dbusmock

On the road to libfprint and fprintd 2.0, we've been fixing some long-standing bugs, including one that required porting our PAM module from dbus-glib to sd-bus, systemd's D-Bus library implementation.

As you can imagine, I have confidence in my ability to write bug-free code at the first attempt, but the foresight to know that this code will be buggy if it's not tested (and to know there's probably a bug in the tests if they run successfully the first time around). So we will have to test that PAM module, thoroughly, before and after the port.

Replacing fprintd

First, to make it easier to run and instrument, we needed to replace fprintd itself. For this, we used dbusmock, which is both a convenience Python library and way to write instrumentable D-Bus services, and wrote a template. There are a number of existing templates for a lot of session and system services, in case you want to test the integration of your code with NetworkManager, low-memory-monitor, or any number of other services.

We then used this to write tests for the command-line utilities, so we can both test our new template and test the command-line utilities themselves.

Replacing gdm

Now that we've got a way to replace fprintd and a physical fingerprint reader, we should write some tests for the (old) PAM module to replace sudo, gdm, or the login authentication services.

Co-workers Andreas Schneier and Jakub Hrozek worked on pam_wrapper, an LD_PRELOAD library to mock the PAM library, and Python helpers to write simple PAM services. This LWN article explains how to test PAM applications, and PAM modules.

After fixing a few bugs in pam_wrapper, and combining with the fprintd dbusmock work above, we could wrap and test the fprintd PAM module like it never was before.

Porting to sd-bus

Finally, porting the PAM module to sd-bus was pretty trivial, a loop of 1) writing tests that work against the old PAM module, 2) porting a section of the code (like the fingerprint reader enumeration, or the timeout support), and 3) testing against the new sd-bus based code. The result was no regressions that we could test for.

Conclusion

Both dbusmock, and pam_wrapper are useful tools in your arsenal to write tests, and given those (fairly) easy to use CIs in GNOME and FreeDesktop.org's GitLabs, it would be a shame not to.

You might also be interested in umockdev, to mock a number of device types, and mocklibc (which combined with dbusmock powers polkit's unattended CI)

Fresh software from the 3.14 menu

Here is a small recap of the GNOME 3.14 features I worked on. Some are already well publicised, through blogs:

• Brought maturity to GOM. It's now usable for real applications (including a number of grilo plugins), and will be gaining features for the more demanding uses soon (such as batched writes), along with gjs support.
• Made the default firewall experience on Fedora better (and made Sharing better on every NetworkManager-using Linux distribution, by the same token).
• Automatic rotation for Windows 8 certified devices. This will still need more work to be integrated into systemd/udev or GNOME.
• Worked on architecturing the Sharing functionality between applications which will be required for sandboxed applications.
• A bit last minute, but Totem now works on Wayland, triggering more bugs in the stack.

And obviously loads of bug fixes, and patch reviews. And I do mean loads :)

To look forward to

If all goes according to plan, I'll be able to merge the aforementioned automatic rotation support into systemd/udev. The kernel API is pretty bad, which makes the user-space code look bad...

The first parts of ebooks support in gnome-documents have already been written, scheduled for 3.16.

And my favourites

Note: With links that will open up like a Christmas present when GNOME 3.14 is released.

There are a lot of big, new features in GNOME 3.14. The Adwaita rewrite made it possible to polish the theme greatly. The captive portals support is very useful, the travelling you will enjoy this (I certainly have!).

But my favourite new feature has to be the gestures support in gnome-shell. I'll make good use of that :)

Sixaxis support in BlueZ

Getting the Sixaxis PlayStation 3 joypad to work with Linux (in Bluetooth mode) is a bit of a pain. There were my various attempts at cleaning up the code lying around on the Internet, and hacks involving hidd.

The way to set the pad up in Bluetooth mode is fairly straight forward:

• Open the USB device
• Get the device's Bluetooth address through magic USB commands
• Write your Bluetooth adapter's address in the pad (magic USB commands again), and then give the device back to the USB HID driver, so that it works as a pad through USB.
  
• Set up the internals of bluetoothd so it recognises the device, and allows it to connect to your computer
• When the device connects through Bluetooth, poke at it with magic commands again to enable its HID mode (code is already in bluetoothd's input plugin)
  

Yesterday I refactored my code as a bluetoothd plugin.

First up, detecting the device being plugged in. I wanted to use DeviceKit's GObject helper library, but it uses the D-Bus DeviceKit daemon which will be going away (note, this is just the DeviceKit daemon itself, not the -power, or -disks "sub"-daemons), in favour of libudev usage.

So I ported devkit-gobject to use libudev directly. Patch is currently being reviewed (it's in DavidZ's inbox), and it should show up soon in udev-extras under a different namespace.

After a bit of work, I had a bluetoothd plugin that detected PS3 pads being plugged in, and did the necessary work to make bluetoothd recognise it on plug.


Next, finishing up the libudev GObject helper library, and getting the bluetoothd plugin reviewed. And it would be nice to finally get the extra functionality merged into a hid driver in the kernel.

PS: Any info on the PS3 Headset or the keypad?