Ray Strode

So, today I’ve decided I want to talk a little about smartcard support in the login screen and unlock dialog.

In the GNOME 2 days users could log into their machines with a smartcard by installing the GDM simple-greeter smartcard plugin. It managed tweaking the UI of the greeter, and calling out to the pam_pkcs11 PAM module (by means of a gdm daemon d-bus interface). Once they were logged in, they could configure their system to lock or log out when the smartcard used to login was removed.

In a GNOME 3 world, the login screen is handled by gnome-shell, so the smartcard plugin is no longer applicable. Early on, we brought support to the gnome-shell based login screen for fingerprint login, but we punted on smartcard support since it’s more niche and we had more pressing issues. So, getting smartcards functiong again is something that’s been on my TODO list for quite a while.

The first step was to resurrect the old gnome-settings-daemon smartcard plugin. It was disabled due to bitrot (see bug 690167). It was previously used soley in the user session for handling the aforementioned screen locking/forced logout on smartcard removal. In a GNOME 3 world, the login screen session uses all the standard gnome components, including gnome-settings-daemon, so we have the oppurtunity to do a nicer job architecturally, by leveraging the settings daemon for the login screen’s smartcard needs as well.

The login screen doesn’t actually need to know a lot about smartcards; all it really needs to know is when a smartcard is inserted or removed, so it knows when to fire up pam_pkcs11 to do the heavy lifting and so it knows when to reset the login screen back afterward. So, the gnome-settings-daemon’s smartcard plugin needed to advertise what smartcards are known and when they get inserted and removed. This is a perfect use case for the D-Bus ObjectManager interface. Every smartcard token gets represented by its own D-Bus Object, and that object implements a org.gnome.SettingsDaemon.Smartcard.Token interface that has an IsInserted property (among other properties). Thankfully, a lot of the murky details of implementing this sort of thing are code generated using the gdbus-codegen tool. But, of course, once the gnome-settings-daemon support landed, we needed to hook it up in the shell.

But before I could do that, we had to do some code clean up. You see gnome-shell has a login screen and an unlock dialog, that both look and act very similar but aren’t implemented using the same code. Adding new features (such as this) would require a lot of duplicated code and effort. Another long punted TODO item was to consolidate as much of the two codebases as made sense. Now most of the two features are implemented in terms of a common AuthPrompt class (see bug 702308 and bug 704707).

Once the two codebases were consolidated we needed to track the smartcard tokens exported from gnome-settings-daemon. As mentioned it uses the D-Bus ObjectManager interface. But gnome-shell doesn’t have good built-in support for using that interface. So the next step was to add that (See the patch here). Once it was added, then there just needed to be a thin wrapper layer on top implement the smartcard management. See bug 683437 for all the details.

So that’s what happened in broad strokes.