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 :)

More power management changes

As is becoming common, we will have some more power management changes in GNOME 3.12, though those changes will also affect other desktops, whether they use UPower's D-Bus interface, or libupower-glib, the helper library.

The goals of the exercise were simple:

• reduce wake-ups on the daemon and on the client side
• reduce code duplication amongst desktop environments, and even within the same environment (composite battery, anyone?)
• moving some policy actions to a lower level (one could not request hibernation or suspend when multiple users were logged in without interaction and passwords)

All those changes are now in UPower master ready for testing.

Out with the old

The deprecated interfaces for Suspend, Hibernate, etc. are finally removed, after being obsoleted by logind. We've also removed the QoS interface that nobody was using, and the out-dated battery recall support. It's not that batteries don't explode any more, it's that they don't all come from known-bad batches.

In with the new

We have 2 new properties on each of the devices.

WarningLevel which uses daemon-side configurations to tell you whether a device's battery level is low, critically low, or whether we're about to take action on that critical level.

We also have IconName, which replaces some cut'n'pasted code between desktop components. If your desktop environment has many more icons for all types of devices on low battery, for example, you can ignore this property and use the code you always have.

Using those new properties usefully is the new DisplayDevice object. It groups all the batteries and UPSes in the daemon into one, easy to use object that you can use to display a single status icon in your shell chrome. Obviously, if you want to show more devices, the individual batteries and UPSes are still available through the usual means. And it obviously has the 2 new properties mentioned above, so your session daemon can get told when to show notifications for low batteries.

And finally, using that new combined DisplayDevice is the critical battery action policies. As mentioned above, multi-user systems could not hibernate without requiring the user to enter an administrator password, which is less than convenient when your machine is running out of UPS power fast. The configuration for that policy is now in the daemon itself, with sane defaults, and it will hibernate the machine for you.

And to the modernisation

libupower-glib now uses GDBus, even if the daemon doesn't. The daemon however sends PropertiesChanged signals which means that modern D-Bus bindings will automatically get the new values for properties, instead of polling the daemon. The DeviceChanged and Changed signals have thus been removed.

API changes

They are numerous, too many to mention here. I've posted to the device-kit mailing-list with a list of changes that were made, reply there if you have any questions regarding using UPower in your application or session daemons.

Miscellaneous

systemd >= 207 will save your brightness settings across reboots, and the upcoming systemd 209 will have support for saving keyboard backlight across reboots.

I've made attempts at supporting Intel Rapid Start in systemd, but this will actually require kernel changes. Hopefully we should be able to land this by the time GNOME 3.12 is released.

Pretty, oh so pretty

There was a tiny problem with the Bluetooth panel has it was implemented in GNOME 3. There wasn't a way to rename the Bluetooth adapter. Well, there was a way, but it wasn't implemented, but it was there, in our minds.

We started by adding support to the Info panel to set a machine's pretty hostname, as implemented by systemd. Looks simple enough.

The next step was to make bluetoothd know about this file, and use it to name Bluetooth adapters, instead of crappy hostnames. And voila.

Implemented as it should be.

If you have applications where using a device's name (as opposed to the user's name) makes sense, please look into using the machine's pretty hostname.

If you want to test all this, packages will soon be trickling into Fedora 16 (aka Rawhide). All the patches are upstream, though the bluez patches are still pending.

Get your hot (beta) GNOME 3 distro!

Want a distro with all the best gizmos? systemd, with learning read-ahead for faster boot? GNOME 3 getting out of your way so you can do work? And much more.

Get Fedora 15 Beta now!