Ray Strode

So, when a user turns on their computer, boot ups, and then enters their username, password, etc, under the covers GDM is using a framework called PAM to do the heavy lifting of processing the login request. PAM is a fairly old, and established library that reads a “service” file to determine what plugins to load, and in what order to load them. The plugins determine what questions to ask the user, verifies the answers the user gives are acceptable, and things like that. As an example, one pam module is pam_unix which will get GDM to ask for a username and password that get checked against /etc/passwd and /etc/shadow (in a lot of cases anyway). Another example, is a module called pam_rps that makes the user play rock-paper-scissors instead of entering a password. Some PAM modules may not want text answers at all, though. For instance pam_fprintd just waits for the user to swipe their finger.

Traditionally, applications that use PAM only ever have one conversation running at a time. That one service file is loaded up and that service file’s stack of modules are run through in order as defined by the policy in the file. If a user wants fingerprint and password support, then they have to use a service file that mentions both pam_unix and pam_fprintd, and the modules have to provide some way to “fall through” to the next module. That means potentially giving up on waiting for fingerprint after 30 seconds and then jumping to pam_unix to ask for password, or something suboptimal along those lines.

Of course, ideally a user doesn’t want this serialized behavior. Instead, they want to either be able to type their password right away or swipe their finger right away and have the right thing happen.

One solution, that’s been slowly trickling in from a branch in git for quite a while, is to run multiple PAM conversations concurrently. I’ve deemed this ‘multi-stack’ or ‘split authentication’. So we can have the “password” stack of pam modules and the “fingerprint” stack both cheefully running along, independent of each other. If the user satisfies the requirements of one of the conversations (say by swiping their finger or entering their password), we cancel the other and proceed with login.

It’s a useful feature, and I finally decided to cut the remainly bulk of the work over to master yesterday in time for the 3.1.2 release. distros will have to enable it with –enable-split-authentication=yes passed to configure, and probably need to modify their pam configurations to accomodate.

I wouldn’t say it’s in perfect shape (in particular the greeter plugin interface is pretty unpleasant), but I wanted to land it now since it’s been lingering on the branch for so long. I’m sure there will be follow commits to deal with unexpected breakage as distros pick it up.

Next thing I’d like to do for 3.2 is get more GNOME 3 integrated greeter. I’ll try to do a follow up post about that soon.