Multiple concurrent authentication conversations
June 14, 2011
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.
Video 4-way split screen gstreamer pipeline
October 11, 2009
So I’m at the Boston Summit this weekend. Mo showed off her portable usability lab. She posted about the lab before here. Jason Clinton posted a summary of the summit session here
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.
those dialogs
October 10, 2007
So there has been a lot of discussion recently about the key import dialog in PackageKit recently. We were talking about it on the bus on the way to work this morning, in fact. Here’s my thoughts (and some thoughts I didn’t come up with, but came from the bus discussion):
- Showing the fingerprint in the dialog is only useful if the fingerprint is somewhere else the user knows to look
- You obviously can’t put where to look in the key itself, because the key isn’t trusted until the fingerprint is verified
- Since you can’t put it in the key, discoverability is a hard problem. We pretty much have to hope that the key is in plain view on the website that offers the package / repo.
- “trust” is a bit of a stretch in any case, because often users will google around for software and install whatever they find. It’s really more “verify the software comes from the website that originally pointed to the package / repo file.”
- Only users who really understand the security implications of the dialog are going to verify that the key fingerprints match
- Given that most people who see the dialog aren’t going to verify that the key fingerprints match, the dialog isn’t useful for security (it only solves the identification problem for a small subset of users)
- One way to make the dialog more secure would be to treat the fingerprint like a CD key / activation number that the user has to enter instead of something that gets shown to the user. If entering the key was a required step for configuring a system to use a repository, then websites that offer repositories would have to include the fingerprint with the repo in plain view for the repo to be useful, and users couldn’t just click past the dialog without reading it.
- Some might argue that users are accustomed to entering these types of numbers already when installing software. There’s precedent anyway.
- Having to enter long strings of numbers sucks (just as much as having to read long strings of numbers sucks)
- Either way, there’s a very real aesthetic problem with this type of dialog, and it’s not clear there’s an easy way to fix that
- One thing that can help is have the distribution know about a select number of 3rd party repos/keys out of the box, so then the dialog can hide the key fingerprint entirely.
- Figuring out which keys to ship within a distribution is an interesting problem itself, but maybe it should have some parallels to the processes that the distribution uses for adding packages?
screensaver extension
July 25, 2007
So during GUADEC I investigated autologin/followed by auto-locking the screen. The idea is a user may want to setup their machine such that they can turn it on, go get coffee, and come back to it all loaded (but locked).
One snag I ran into was that gnome-screensaver’s screensaver and the various components of the desktop (panel, splash screen, background, etc) would race to be on top of the window stack. The splash screen would pop up, then the screensaver would raise over it, then the panel would pop up and the screensaver would raise over it, etc. It was very flickery.
One solution to this is to use the MIT screensaver extension included with X. It provides a really-truely-always-on-top window that things like the splash screen and panel can’t ever raise over.
The screensaver extension has been rejected in the past for a few reasons:
1) We didn’t think we could get a fade in animation prelock since X maps the screensaver window automatically instead of letting gnome-screensaver do it
2) We didn’t think we could get separate screensavers running per head in a xinerama multihead setup since the screensaver extension only provides one window that covers the entire X screen (and so spans all the heads in xinerama setup)
3) We didn’t think X could reasonable know when the system was idle since there are more forms of user activity than input devices.
I wrote a little test program that demonstrates the first two issues are resolvable, and posted about it here:
http://mail.gnome.org/archives/screensaver-list/2007-July/msg00007.html
The fix for the first issue is to use a None background pixmap on the screensaver window so that when it gets mapped the contents of the screen don’t get erased and we can fade from there.
The fix for the second issue is to run the screensavers on child windows of screensaver window instead of on the screensaver window itself.
Login Records
June 29, 2007
So one of the the features I needed to implement for RHEL 5 was btmp logging for GDM. The btmp log is a record of failed log attempts that an admin can access by running the /usr/bin/lastb command. It’s similiar to the wtmp log which is a record of login and logouts by users, and also like the utmp log which is a record of users currently logged in.
GDM already had indirect support for those last two types of login records because when starting a session it would invoke the sessreg utility that ships with X. This utility would create an entry in the wtmp and utmp logs. This utility couldn’t create an entry in the btmp log, however, because it only gets invoked after a session is started, and the btmp log records failed login attempts–attempt that don’t lead to a session getting started.
The format of the 3 logs are nearly identical, so it made sense to do all the logging with in GDM. For RHEL 5, I pushed a patch that did wtmp and btmp logging, but neglected to do utmp logging. The reason for this was a bit of text in the utmp man page
xdm(8) should not create a utmp record, because there is no assigned terminal. Letting it create one will result in errors, such as ’finger: cannot stat /dev/machine.dom’. It should create wtmp entries, though, just like ftpd(8) does.
This turned out to be a mistake. People like to be able to see who is currently logged in by using the w command, which relies on utmp being up to date. I’ll be correcting that in a future RHEL 5 update.
Anyway, I submitted my patch upstream and Brian Cameron picked up the work and made it work in Solaris. This broke it in Linux, so he passed it back to me to fix for Linux.
There is still one issue left. utmp entries have a specific field per record called the ut_line field. For text logins you would put the name of the terminal device that is controlling the session. So if the user is logged in on vt 1, then the associated terminal device is /dev/tty1 and the ut_line field would be tty1.
For X logins, there is no controlling terminal, so there is some debate what should go in the ut_line field. Note, the warning I quoted above. Some utilities expect there to be a file in /dev with whatever value is given to ut_line. According to Brian, Solaris has traditionally dealt with this problem by creating fake files in /dev for each X login, just so programs like finger and w don’t freak out. These fake files are called “pseudo devices” and they’re sort of akin to pseudo-terminals, except they aren’t terminal devices.
Anyway, it’s not clear what we should do for ut_line. The whole idea of creating fake files just to satisfy some old unix utilities is sort of offensive, and it has SELinux implications as well. For RHEL 4, ut_line was not set to a valid file. It was simply the display number (:0 or whatever), so I’m thinking that’s probably the right way to go.
GUADEC
June 9, 2007
So mizmo booked our guadec tickets tonight. We’re flying out tuesday night and coming back monday.
GDM refactoring
June 9, 2007
So Jon McCann of gnome-screensaver and ConsoleKit fame is doing awesome work on refactoring gdm to have a more modern structure to it. In particular, gdm will finally start using dbus to handle IPC instead of its own groady socket protocol. He’s also splitting up the code into coherent chunks and creating various gobjects to manage those chunks.
It’s a pretty huge undertaking but he’s making really good progress so far. He also landed some code that I wrote a year ago to rework the pam handling.