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.

The DVR hardware in the setup ouputs four avi files–one for each camera. The first file has the audio encoded in it. Having four files is cumbersome, though. It’s much better to see the camera focused on the users face at the same time as video focused on the users hands, and at the same time as the view that shows the users screen.

That’s where gstreamer comes in. It’s possible to write a pipeline that can take the 4 videos and compose them together into one 4-way split screen.

In Mo’s post she showed an earlier pipeline I came up with, but it was very slow and lacked audio.

I’ve been reading up on gstreamer, searching the internets for example pipelines, etc, and now have a better pipeline. Someone here at the summit asked for me to check it into git, so I did that today in the usability-lab module.