Right, it would probably be fine to use a gconf key for this. As noted here

 http://lists.freedesktop.org/archives/xorg/2008-April/035026.html

grabbing isn't for security per se.

Novell bug about this: https://bugzilla.novell.com/show_bug.cgi?id=384159

(In reply to comment #2)
> Novell bug about this: https://bugzilla.novell.com/show_bug.cgi?id=384159
> 

Don't think this is the same. I believe what you're seeing is a window manager bug; in PolicyKit-gnome we do

 gtk_window_set_keep_above (window, TRUE);

in src/polkit-gnome-auth-dialog.c. This might be related to bug 519188.

Ah, thanks for the pointer.  The patch in that bug indeed makes things better, but it doesn't work in this configuration:

- Use click-to-focus in Metacity.
- Have a full-screen window with the input focus (e.g. gedit)
- bring up the panel clock's popup
- Click on "Set" in a timezone

The auth dialog will appear above the full-screen window, but *below* the clock's window.

This works fine in sloppy-focus.

CCing the Metacity maintainers for advice.

My opinion is that system modal windows aren't possible to implement sanely with current X protocol and X specs (ICCCM, EWMH).

In the past when this came up on the wm-spec-list I think people were opposed to adding a way to do it.

So, I think the grab is definitely bad and wrong. The way to avoid typing passwords in IRC is focus stealing prevention. But IIRC policy kit is also disabling focus stealing prevention, which is also bad and wrong.

Finally I think setting keep_above is bad and wrong, because the dialog should already have type DIALOG and be set as transient for anything it's transient for if it is. And so the WM should do the right thing, and if not, it's a WM bug. 

There's nothing "special" about a policy kit dialog that it should be "more above" than a regular dialog-with-no-parent-app-window. The info that it's a dialog and has no transient parent should be sufficient for the WM to figure out what's going on.

So my short answer is delete all the hacks in PolicyKit: keep above, defeating focus stealing, and the grab. Then fix the window manager if you need to.

The reason this stuff has to be handled in the WM is that apps can't get it right because they lack sufficient global knowledge of what's going on with other windows. So stop trying.

In the WM, for example, the WM would know about the clock's window. So in principle you could fix that.

I could be wrong, but, I doubt it. If PolicyKit needs to do anything, at most it's setting some additional *semantic* hint. And then it's still a WM issue after that to figure out the details of layering, focus, grabs, and focus stealing. All the app should need to do is correctly describe itself and the situation through proper semantic hints and (in the focus stealing case) proper timestamps.

You cannot fix this in the app.

(If we wanted to allow system modality, it would involve some type of protocol where the WM knew about the grab and would thus carefully keep that window on top of everything else, and so forth)

The bottom line is that the way X is designed, if a WM does not support what you want to do, you just can't do it, not sanely anyway. In the past we've always had to extend the WM to definitively make things like fullscreen mode work correctly.

If you don't like it, then start moving window management into the toolkit and we will all see you in 2014 or so ;-)

Note that keep above has a "relative" meaning to the semantic type and other info about a window and overall state of the desktop; it doesn't mean "absolutely above everything" because then as soon as you had two keep above windows, there would be an infinite loop. "absolute" above-ness is computed by the WM taking into account all the semantic hints, and can't be requested by apps due to the infinite loop issue.

If you want just the advice and not the lecture, the way I would attempt to make this work would be to extend EWMH (or just the WMs of your choice) to support some kind of system modality protocol.

But, in all honesty, I have no clue how to fix it in all cases/situations by modifying only the app. The X architecture with a separate WM really does mean some stuff isn't possible without WM mods.

Thanks for the lecture, HP :)

I was talking to DavidZ about extending the PolicyKit protocol to have something like

   pk_may_i_do_this ("org.gnome.some-action",
                     transient_parent_window_id,
                     x_timestamp)

so that the auth dialog could use the right WM paraphernalia when setting itself up.  *That* looks to me like the most GUI-friendly approach, and it would avoid any hacks.

(It would also match the pattern that we had in GTK+ --- we had to add "_with_time" counterparts to a bunch of existing "show a window"-type functions.)

Hi,

Havoc, thanks for explaining how this works.

I'm not sure how to best deal with this. Technical issues aside, the point of the PolicyKit isn't really these authentication dialogs (as per the link in comment 1). In fact, like most other dialogs, they're a disease and during normal operation on a properly configured system users shouldn't need to see them. 

However, it's useful for the trusted path feature which I think we want for some things where you really want to know that the intent to do something dangerous stems from a human being (e.g. the user confirming that the modem dialler is allowed to call some 1-900 number @ $50 / minute on the other side of the world. Installing unsigned software is another example.). 

The main objective here is to be somewhat resilient in the event the user has malware running in his session. Certainly, this is a huge problem in Windows, I don't expect it to always be a non-issue under GNOME. Then there's the lockdown angle; some businesses wants to lock down systems and only allow on-site helpdesk staff to do some operations. So in order to mess around with the box at all, some admin password needs to be entered.

So, anyway, the main reason users see these password dialogs _today_ is that they use a general purpose OS and the OS vendor errs on the side of not giving too many authorizations by default. On a more targeted OS, for example a hypothetical "Fedora Laptop Edition" or whatever, the only sane thing is to allow people to do all these rather mundane tasks (changing timezone, installing signed software etc.) without being interrupted by stupid authentication dialogs. On the other hand, the "Fedora KIOSK edition", will not let the user do much (because he's inherently untrusted). Stuff like that.

I guess I'm saying that with time (and hard work from the OS vendors to produce targeted OS editions), we won't see a lot of these authentication dialogs. But occasionally there will be a few of them, for example if you try to install unsigned software. Which hopefully few users will do. So these dialogs will be rare, in a perfect world and all.

So in a way (and this is why I spend so many paragraphs above with background info) I expect it to be a really really big important event if the user ever sees a PolicyKit authentication dialog (as it may indicate an intrusion attempt from malware). As such, I do think it should be system-modal and demand all the attention from the user. It's a really really big deal security-wise if users see it and just clicking through it to quickly entering a password shouldn't be an option.

(As a corollary: we need to work on the dialog to make it more scary, also need to put in a timeout of three seconds before the user can even start the authentication process. Kinda like the Firefox add-on installation dialog.)

For the security related bits: I envision, in some star trek future, that PolicyKit may be configured to use a "secure desktop" only reachable through the Secure Attention Key (e.g. ctrl+alt+delete or similar). Then the user experience is something like this

 1. User lacks an authorization to do something (like setting the timezone) but
    it turns out he can acquire an authorization through authentication

 2. App calls into the org.fd.PK.AuthenticationAgent interface

 3. polkit-gnome-manager (that provides this interface; on KDE it might be
    polkit-kde-manager etc.) brings up a dialog explaining an authentication
    is needed. Also asks user to press the SAK (e.g. ctrl+alt+delelte) to
    get to the authentication dialog

 4. Another X server is launched and we switch to that (ideally through fading,
    maybe it displays the old desktop behind it using alpha-blending). This
    X server is completely unrelated to the users session, everything runs
    as a system user (e.g. polkituser or whatever). It's a secure sandbox.

    - For a11y there will be a way to launch AT's etc. just like on the
      login screen. Perhaps we can be smart about some things and launch
      AT's already running.

 5. The user authenticates on this secure desktop and if successful he
    gains the authorization needed.

 6. The secure desktop is torn down and we return to the normal session.

 7. polkit-gnome-manager returns TRUE to the app that called it.

 8. App tries to use the mechanism again, now it succeeds. Done.

In fact, I'd argue any application dealing with password prompting should do something like this. Such as the screensaver and probably even the file manager when connecting to shares. 

(The alternative to the "secure desktop" is an MLS aware desktop (e.g. labeling the objects in the X server) along with securing the toolkit and what not. Which is even harder to solve.)

(Again, all this work just to ensure that malware can't snoop your passwords etc.)

(I've added Jon McCann to the Cc; he's been doing a lot of thinking about what infrastructure we need in order to have a secure desktop feature. It's just a lot of work.)

So I guess the way forward, unless I'm on crack (feel very free to say so, I occasionally smoke the wrong crack), is to get a system modality hint in EWMH. I expect different WM's can implement it different ways; for example it would be lots of eye-candy and look pleasing if e.g. the rest of the desktop was faded down to black and slightly minimized (like the Alt-Tab dialog in Compiz).

So, to conclude, long-term I think we should

 - get a system-modal hint into EWMH and make metacity, compiz honor it

 - work on SAK / secure desktop; then port the PolicyKit-gnome
   authentication dialogs to take advantage of it

For the short-term, I think we should

 - extend the PK AuthenticationAgent API as per comment 8

 - avoid grabbing anything or doing special tricks as per comment 5,
   comment 6 and comment 7. I agree it breaks more than it tries
   to fix.

Thoughts?

> In fact, I'd argue any application dealing with password prompting should do
> something like this. Such as the screensaver and probably even the file manager
> when connecting to shares. 

A bit off-topic for this bug, but FWIW, wanted to point out that gio/gvfs is already prepared for this kind of thing

 http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00149.html
 http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html

I can think of a use case beyond policykit where this would be useful.

There's some a11y dialogs -- the slow keys and sticky keys alerts -- that would benefit from this.   By virtue of how they work, they modify how your keyboard operates as soon as you've activated them (by pressing shift for a long time or pressing it repeatedly), and they have to modify the keyboard instantly for it to be useful to a11y users.  The dialogs pop up to inform the users of the change, and give them a chance to dismiss the windows.  But there have been instances of users accidentally triggering these dialogs (I've done it before) and then also either not seeing the dialogs that come up (they came under windows or the user switched desktops quickly or something of that nature...) or the users cliked/typed too fast and dismissed these dialogs before getting to read them.  There's a bug open about this in bugzilla somewhere, against metacity.

Anyway, some kind of system-modal dialog (uh, sorry, we screwed your keyboard up so that you can't use it...you really should know about this before proceeding) with a pause before accepting input would be really nice for that too.  (But the separate outside-of-X process would be overkill for that case.)

Created attachment 110671 [details] [review]
policykit-gnome-bgo531609-no-grabs.diff

This patch does what I discussed with DavidZ:

* Don't grab the mouse.

* Grab the keyboard only if the /desktop/gnome/policykit/auth_dialog_grab_keyboard GConf key is set.

For now, I'm putting this patch in openSUSE's package, for https://bugzilla.novell.com/show_bug.cgi?id=384159

Comment on attachment 110671 [details] [review]
policykit-gnome-bgo531609-no-grabs.diff

Committed thanks. I also added the schemas.in file to POTFILES.in.

Cool, thanks :)  I forgot about POTFILES.in.

With this, I think we can close the bug for now, and worry about "really secure" X dialogs later.  What do you think?

If it is not already the case, could you please consider adding an option to disable the pointer grabbing dialog directly on the authentication dialog? That option could for example act on the corresponding gconf key. 

This way, it would be more user friendly, and above all, non initiated users would be informed about the available work around. Of course, the option should be followed by a confirmation dialog informing the user about the security risk of input focus stealing involved with the disabling of the pointer grabbing. 

(In reply to comment #15)
> If it is not already the case, could you please consider adding an option to
> disable the pointer grabbing dialog directly on the authentication dialog? That
> option could for example act on the corresponding gconf key. 

We no longer grab the pointer at all.

Grabbing the keyboard is configurable with the GConf key /desktop/gnome/policykit/auth_dialog_grab_keyboard

See comment #12 for the actual patches that went in.

Sorry, I misunderstood the solution: I thought that there was a gconf key to disable pointer grabbing; which is wrong. There is no pointer grabbing anymore. 

Thanks for the clarification. 

A new release of policykit-gnome has appeared in debian unstable on the 24th of july 2008.

I think that it contains the fix for this issue and I suppose that this bug can be closed!? 

Yes, thanks for the reminder - indeed this is fixed now.