Monday, February 21, 2011

GNOME 3 Authorization

The past couple of days I've been working on implementing the GNOME 3 Authorization Dialog. The implementation uses PolicyKit to achieve this and is conceptually very simple: the Shell process itself just implements the org.freedesktop.PolicyKit1.AuthenticationAgent interface to handle authentication requests from the system-wide authority (video).

For authentication, the Shell is using the existing code that in turn uses PAM. This means that the Authorization Dialog will work out-of-the-box with e.g. fingerprint readers, provided, of course, that the PAM stack has been set up correctly (video).

Additionally, the code has been tested with pam_rps - a PAM module whereby you authenticate by proving that you are smart enough to win in Rock-paper-scissors. The idea is that if your application works with pam_rps, then there's a good chance that it will work with any PAM module (video).

One major difference - and something I've been wanting to do for a while - is that the dialogs are now system-modal. In addition to fixing a lot of focus problems, this also makes the dialogs look more trustworthy since they are part of the actual shell. They're also way prettier.

(Bonus chatter: Of course, there's an emphasis on look in the above paragraph because any random app can still go full-screen to fool the user to give them their password. To do this in a more secure way, we need to use the Secure Attention Key and run the dialog in another security context etc. It's an open question whether it's even worth it to do this. But I digress.)

You can find the current code drop in this bug.


  1. With the similar feature on Windows (UAC), there is the annoying situation that when a projector is attached (as a secondary screen to the laptop display) the system-modal password dialog also makes the projected image darker.
    This should not happen. Do you prevent that in the shell implementation?

  2. How does the dialog works in the scenario when you have to choose the account to authorize as?

  3. Maarten: Actually, the shell does that too ..and not only for polkit dialogs, also for alt+f2 etc.. I don't think it's a problem, I think it's actually a feature. Keep in mind that polkit dialogs on a properly configured system are very rare.

    Krzysztof: Right now it just picks the first user. I'm waiting for the designers for input...

  4. In a multi-monitor setup that would indeed be the desired behaviour. But when a projector is detected (is that possible?) at the secondary screen, only the primary screen should be dimmed. Now _that_ would be a feature!
    The same holds (perhaps even more so) for Alt+F2.

  5. So I assume it works also with yubico OTP keys? Uhm, that would be another reason to buy one...

  6. Since this popped up when I was evaluating packagekit recently, how does this work if you have an application which wants to do the authorization instead of the gnome dialog. An example is a media center app which has temporarily taken over the entire interface and you want to upgrade your system or just install a new cool app via this interface instead, while it seems like it can supply the password via PAM it is not able to use its GUI and is forced to use the GNOME3 GUI, which does not necessarily understand the input that the media center does.

    Other, similar, places would be games which like to do some authorization (maybe not to install packages but for some other reason), having it pop out of that GUI for the GNOME3 GUI is not really as integrated as it could be.

  7. Hi, I have a problem: my system has 2 admins, but because it picks the first user, I can no longer use it (I only know the password for the 2nd admin!). anything can be done about that?