Created attachment 143960 [details] [review]
Adds toplevel_xid PolicyKit detail to set transient window for dialog

Proposed patch, not fully tested

Created attachment 143961 [details] [review]
Adds toplevel_xid PolicyKit detail to set transient window for dialog

Updated to make PolkitLockButton supply its window ID

Raising importance, this is a bit of a security issue.

The way this should work is that the authentication dialog needs to be system modal. Which means that all monitors that is part of the session should do something like fade to transparent black or something and the dialog should be presented.

FYI, the design of PolicyKit allows for authentication agents that are not even part of the desktop session or even on the same machine. The long term plan is to have a "secure desktop session" (with it's own X server and a minimal set of known and trusted bits running in it) for each real session.

With such a secure desktop session, we'll just do a fast-user-switch to the when authentication is needed - and maybe we'll required the user to use the Secure Attention Key (e.g. ctrl+alt+delete) to get to it. That way the user can safely authenticate and no-one can snoop on the password being entered. FWIW, we most likely want to the secure desktop for the gnome-screensaver unlock dialogs, GMountOperation dialogs etc. but that is a separate thing.

Also, keep in mind that the polkit authentication agent could also be a separate _device_. For example, imagine that you have a USB device with a small LED display and a red button attached. The "authentication" bit of this is merely pressing the red button. Another example could be an authentication agent running on your phone.

If there is an issue here, it's the fact that focus-stealing prevention in the WM causes the authentication dialog to not be presented as system modal. That is a WM bug because there is, AFAIK, no mechanism to do system modal dialogs.

And, FWIW, there's really no security issue here - you can't really gain anything because of the fact that the WM makes it hard for the user to spot the dialog. 

I'm closing this as NOTABUG. I know this is not a very satisfying answer but the bug is really with the window manager and/or the EWMH spec.

PolicyKit's main user experience advantage over gksu is that it is not system-modal: you are not forced to cancel or authenticate for that particular task before doing anything else with the computer (such as continuing to read a help page for the task). If PolicyKit alerts became system-modal, that would be a regression. (And if you also needed to type Ctrl Alt Delete or a similar archaism before authenticating, that would be even worse.)

Our issue is not "that focus-stealing prevention in the WM causes the authentication dialog to not be presented as system modal". Our issue is that the authentication alert does not tell the WM what it needs to know to make an alert *window*-modal. In the cases we want to use this mechanism, there is nothing else you can/should do in the parent window while the alert is open. So just as with any other window-modal dialog, the authentication alert should become focused whenever you had focused (or try to focus) the parent window.

(In reply to comment #5)
> PolicyKit's main user experience advantage over gksu is that it is not
> system-modal: you are not forced to cancel or authenticate for that particular
> task before doing anything else with the computer (such as continuing to read a
> help page for the task). If PolicyKit alerts became system-modal, that would be
> a regression. 

The main point about this feature is to check that the human being in front of the system, that initiated some action, needs to prove that he is really is either 1) the user; or 2) the administrator. Without any special hardware assist, this means asking for something the human (and not his login session) knows - the password (or the root password).

This is a pretty big deal, especially since we are asking for very sensitive things such as the user password or the root password. In other words, it's just not another random window popping up. So we need to treat it in a special way so people feel more comfortable giving away such sensitive information. Hence system modal.

FWIW, I don't think it's a good idea just to keep password dialogs hanging by allowing the user to do other tasks... because if we did, then the user might see the dialog 30 minutes later and forget why it had popped up. Doing it like this also helps to undermine the confidence the user may have in the system - e.g. it strengthens the perception that it's fine to enter your user or root password into any random window.

I agree that window-modal is right for other authentication tasks such as logging into your webmail account or connecting to a file share or ftp server (e.g. you really want to be able to look in a text file for the password because that's how people manage passwords (!) - window-modal allows this). But it is not right for polkit (and if the user needs to lookup his user or root password in a text file... then it is probably not the user - I mean, how would he have logged in in the first place?).

Remember that the point of PolicyKit is not really the authentication dialogs. In fact, for a consumer laptop, a properly configured OS would never need to pop up authentication dialogs. We're not nearly there but

https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html

gives an indication about how we'll get there. But that involves a lot of work actually creating a sensible user account editor with simple check buttons like

 [O] This user has administrative privileges
 [ ] This user has limited privilges
 [ ] This user is a guest

Or something.

> (And if you also needed to type Ctrl Alt Delete or a similar
> archaism before authenticating, that would be even worse.)

Sure, I would hate if my system started making me do this - it's insane for a consumer OS! But this feature _is_ needed (because of policy or legislation (e.g. sarbox)) for some sensitive environments where you don't want to trust the rest of your session - for example, a rogue app might pop up a fullscreen window that *looks* like an authentication dialog - and thereby steal the password. Requiring such users (and educating them that they need to do that) to press the SAK (e.g. ctrl+alt+del) before entering their user or root password is a way to avoid that.

This feature, once we land it, would definitely be off by default for consumer installs - but customers with such needs would be able to turn it on as needed.

> Our issue is not "that focus-stealing prevention in the WM causes the
> authentication dialog to not be presented as system modal". Our issue is that
> the authentication alert does not tell the WM what it needs to know to make an
> alert *window*-modal. In the cases we want to use this mechanism, there is
> nothing else you can/should do in the parent window while the alert is open. So
> just as with any other window-modal dialog, the authentication alert should
> become focused whenever you had focused (or try to focus) the parent window.

This paragraph assumes that window-modal is what we want. Which it is not. Right now it's just a _bug_ that the polkit authentication are not system modal. Hopefully we'll fix that bug in a later release.

I understand the need to "treat it in a special way so people feel more comfortable giving away such sensitive information". But if the alert was system-modal, people couldn't consult the help to check whether they were supposed to be entering their password at this point, and nor could they ask someone on IM or IRC or VoIP whether it's supposed to be happening. Hence, they would be less comfortable about doing it, not more. Give a graphic designer a day and I'm sure they could show you a dozen ways a PolicyKit alert could be presented specially without being system-modal. (If you'd like, I could ask one of my colleagues to do this.)

I also recognize that the point of PolicyKit is not the alerts, but the occasions where they do appear are what this bug report is about. And "To uninstall OpenOffice.org, you need to authenticate" makes a better tradeoff between brain-fart prevention and non-aggravation than anything else I know of -- certainly better than either a plain confirmation alert, or nothing at all. So while in high-security environments the authentication alert may need to be system-modal, and elsewhere it should sometimes not be modal at all, in many cases window-modal is indeed what we want.

(In reply to comment #7)
> I understand the need to "treat it in a special way so people feel more
> comfortable giving away such sensitive information". But if the alert was
> system-modal, people couldn't consult the help to check whether they were
> supposed to be entering their password at this point, and nor could they ask
> someone on IM or IRC or VoIP whether it's supposed to be happening. Hence, they
> would be less comfortable about doing it, not more. 

Mpt , what are the chances of the scenario you'v described happening compared to all the problems  David Zeuthen  listed ? 
Though the new user getting frightened with the system modal can occur . How often will they arise. The user will get scarred once... twice? or at the max 10 times? after that wouldnt the user know by then what the prompt is for and surely not get frightened why the system modal occurs?

After which all the problems David Zeuthen , described will still remain.

Isnt the root cause of this problem due to lack of familiarity with the way linux authentication works rather than problems with the way it is works.

When user gets frightened , there also exists a cancel button , so user can escape from the prompt and
Wouldnt it be better
- if the text in the prompt explains  , why the prompt is being presented.
- introducing the OS features to the user in a better manner [Ubuntu has started a slideshow , maybe adding a slide for these prompts ?]

May not be the best solutions , but not using a system modal for the transient problem of lack of awareness does not seem ideal.

(In reply to comment #7)
> I understand the need to "treat it in a special way so people feel more
> comfortable giving away such sensitive information". But if the alert was
> system-modal, people couldn't consult the help to check whether they were
> supposed to be entering their password at this point, and nor could they ask
> someone on IM or IRC or VoIP whether it's supposed to be happening. Hence, they
> would be less comfortable about doing it, not more. Give a graphic designer a
> day and I'm sure they could show you a dozen ways a PolicyKit alert could be
> presented specially without being system-modal. (If you'd like, I could ask one
> of my colleagues to do this.)

The way PolicyKit is supposed to be used by mechanisms/apps is that authentication dialogs should only pop up in response to user initiated actions. Anything else is a bug in the mechanism/app using polkit. So I think it's fine for people to just press cancel on the system-modal, consult help/IRC/IM, and then do it again. 

Whether users figure this out is indeed the $64,000 question though - I think most users do since the authentication dialog popped up right after clicking a button. E.g. they go "click the Foo button, wow a scary dialog, think "hmm, it popped up in response to clicking Foo button so I can get back to it", click the Cancel button, ask buddy on IRC about it, click Foo button again, authenticate, done".

> I also recognize that the point of PolicyKit is not the alerts, but the
> occasions where they do appear are what this bug report is about. And "To
> uninstall OpenOffice.org, you need to authenticate" makes a better tradeoff
> between brain-fart prevention and non-aggravation than anything else I know of
> -- certainly better than either a plain confirmation alert, or nothing at all.
> So while in high-security environments the authentication alert may need to be
> system-modal, and elsewhere it should sometimes not be modal at all, in many
> cases window-modal is indeed what we want.

First, we really shouldn't use polkit authentication dialogs as substitutes for confirmation dialogs - these are very different concepts and it varies, depending on deployment details, whether you get the former at all. So I don't think you can use this as an argument for polkit authentication dialogs being window-modal.

In my view, even uninstalling a package, shouldn't require the user to type in his password. The way the OS is supposed to work, from a 50,000 feet view, is that for the home-user/laptop case we should never ever slow down the user with authentication dialogs for 99% of the workloads. Not even uninstalling software.

The only cases where it makes sense to pester the use with authentication dialogs in such a setup (e.g. home-user/laptop) is for cases like

 - installing unsigned/untrusted software
 - setting up a modem connection (e.g. avoid malware modem diallers)

which is something that shouldn't happen too often.

Everything else should be allowed without authentication dialogs in a default OS install for home-user/laptop (even updating the OS with trusted packages). The admin (if there is one) can always override this according to company policy or similar (e.g. parents might want to limit their kids accounts to avoid them installing new games etc).

(Related: Yes, it is annoying to get both a confirmation dialog and _then_ an authentication dialog. But I think enterprise users can live with that - the main thing here is that we should never have authentication dialogs in the home-user/laptop case.)

I'm going to repurpose this bug for "Make authentication dialogs system-modal and improve wording" as described in comment 6 and comment 9. Any thoughts/ideas/mockups/design on this is more than welcome. Thanks.

Note, there's related gnome-shell discussion going on here:

http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemDialogs

And here:

http://mail.gnome.org/archives/gnome-shell-list/2010-September/msg00014.html

> Mpt , what are the chances of the scenario you'v described happening compared
> to all the problems David Zeuthen listed ?"

The only issue I see is "the user might see the dialog 30 minutes later and forget why it had popped up". But if that's a problem, it's a problem not just 30 minutes later, but also when the dialog first appears. (Sebastian Heinlein and I have fixed many PolicyKit strings in aptdaemon to address this, for example.) And it would be even *worse* if returning after 30 minutes to a computer showing a system-modal dialog, because it wouldn't be attached to an individual window, so it would be harder to tell what the context was.

> So I think it's fine for people to just press cancel on the system-modal,
> consult help/IRC/IM, and then do it again."

Even if that would have been okay six months ago, it no longer would be now. aptdaemon's PolicyKit dialog saying "To install purchased software, you need to authenticate" necessarily appears *after* submitting the payment (currently about 11 seconds later, depending on connection speed and server load). It's possible to cancel and then to restart the installation later without paying again, but that's naturally a lot more nerve-wracking than leaving the dialog open in the first place.

(In reply to comment #13)
> > Mpt , what are the chances of the scenario you'v described happening compared
> > to all the problems David Zeuthen listed ?"
> 
> The only issue I see is "the user might see the dialog 30 minutes later and
> forget why it had popped up". But if that's a problem, it's a problem not just
> 30 minutes later, but also when the dialog first appears. (Sebastian Heinlein
> and I have fixed many PolicyKit strings in aptdaemon to address this, for
> example.) And it would be even *worse* if returning after 30 minutes to a
> computer showing a system-modal dialog, because it wouldn't be attached to an
> individual window, so it would be harder to tell what the context was.
> 
> > So I think it's fine for people to just press cancel on the system-modal,
> > consult help/IRC/IM, and then do it again."
> 
> Even if that would have been okay six months ago, it no longer would be now.
> aptdaemon's PolicyKit dialog saying "To install purchased software, you need to
> authenticate" necessarily appears *after* submitting the payment (currently
> about 11 seconds later, depending on connection speed and server load). It's
> possible to cancel and then to restart the installation later without paying
> again, but that's naturally a lot more nerve-wracking than leaving the dialog
> open in the first place.

Without knowing anything about this aptdaemon you speak of, it seems like it would be smarter to do things the other way around (e.g. ensure you can actually install the software before demanding cold cash from the user). I would probably use a GtkLockButton-ish design. E.g. the "install/buy" button is insensitive until a lock is opened and while open, the user can install all the (signed and trusted) software he wants. Just seems like a better design.

(Btw, there's also a cardinal rule somewhere saying that any interface with transactions should be fail-safe at *any* point - e.g. you have to be able to resume the transaction at any point. This is especially important if the transaction is of monetary nature, of course. This is not only for such annoying implementation struggles as what you are facing ("admin authority is needed to install software") but also because the user may lose power or network at any time.)

Bottom line: I don't think these deficiencies in this aptdaemon of yours, means that system-modal is a bad idea.

David, the current state of PolicyKit authentication are that *system-modal dialogs* don't work, as you explained (I didn't know this was even intended). So, I think it would be better to have window-modal dialogs rather than nothing, at least until we find a better solution. No need to discuss the past and future of authentication on desktops for that! ;-)

Currently, we have two important issues, even if authentication is reserved to operations that really require it (installing software, modifying users...):
1) PK auth dialogs appear on their own and float in the desktop
2) sometimes they don't get the focus, which forces people to click on them
Window-modal would improve things on that regard and wouldn't hurt your long-term objective of using a really secured session for that.

(In reply to comment #15)
> David, the current state of PolicyKit authentication are that *system-modal
> dialogs* don't work, as you explained (I didn't know this was even intended).
> So, I think it would be better to have window-modal dialogs rather than
> nothing, at least until we find a better solution. No need to discuss the past
> and future of authentication on desktops for that! ;-)
> 
> Currently, we have two important issues, even if authentication is reserved to
> operations that really require it (installing software, modifying users...):
> 1) PK auth dialogs appear on their own and float in the desktop
> 2) sometimes they don't get the focus, which forces people to click on them
> Window-modal would improve things on that regard and wouldn't hurt your
> long-term objective of using a really secured session for that.

No, actually, this bug is indeed about the long-term solution. Please use other bugs for existing problems.

But the original reporter was providing a fix that he didn't present as a long-term solution. I can open a new bug with copy/paste of this one's description, but I think it would be more logical that you tell us what do you think of this as a short-term solution, and then we keep the bug open, since this discussion will be helpful for the long-term too. ;-)

Passing as much context as possible to PolicyKit is useful.

In the current case we have a basic dialog, so the window manager needs to link that to the requesting application window.  But even if the dialog is system modal you may want to know the window for a transition animation.  The toplevel_xid detail is only a hint and can be ignored; if you had a physical device for authentication then it wouldn't be appropriate.

Created attachment 172396 [details] [review]
Adds toplevel_xid PolicyKit detail to set transient window for dialog

Updated to current master and to use g_strdup_printf instead of GString.

This patch (if it's applied in Natty, as I suspect it is) causes authentication to fail because polkitd denies non-root to set details when checking authorizations. See https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/685655

i think this is obsolete now given polkit dialogs are handled in the shell... if someone disagrees, feel free to reopen.