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.

4 Responses to “Multiple concurrent authentication conversations”

  1. davidz Says:

    Cool. But it would probably have been easier if you just implemented this multistack PAM hack in PolicyKit and then used PolicyKit in the login screen (gdm) and the unlock screen dialog (gnome-screensaver). That way, GNOME would only need to care about authentication in a single place instead of three. I think that would be a big win.

    (btw, let me preempt a common misconception: PolicyKit works just fine on any Unix OS so there is zero excuse for vendors (like Oracle) to not ship it.)

    Btw, while I’m ranting, let me also mention that it would be even better to just replace PAM wholesale with something better that also works better for e.g. thin clients. But I realize that’s more work.

    • halfline Says:

      I definitely agree unifying things make sense. PolicyKit, right now doesn’t do the later stages of the PAM process like session modules etc, so we would need to add those bits. Worthwhile work to do, nonetheless.
      Primarily, my focus with landing this stuff, right now, is to just get rid of the branch, so things don’t fork too far when starting on a more integrated greeter for 3.2. Once that big user-visible peice has landed, it will probably make sense to revisit how screensaver, gdm, and polkit should fit together.

  2. davidz Says:

    Sounds good. (For the record, pkexec(1) actually does the session part of PAM when just before becoming the user (e.g. after authentication but after the setreuid(2) call). The way I read the code is that it does not needs to happen in the same process – consider for example su(1) as super user to your unprivilged user without entering any password.)

  3. […] promised in my last post I’m going to do a follow blog with more details about where GDM is going in 3.2, but for now […]

Leave a Reply