The way it works is that we're expecting the logged in user to authenticate as himself unless otherwise specified. If some other password is required, for example the root password or the password of an administrative user (think systems like on Mac OS X with sudo and no root password), then the dialogs are clear about it, see

http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html

for the various dialogs. Maybe we can do s/Password:/Password for <user>:/ but that won't work for certain PAM setups. I don't know. Maybe it's fine the way it is and the reaction to enter the root password was just an occupational hazard? ;-)

> Also - can we pre-configure this beast so we don't have to authenticate to
> change the time ? ;-)

The upstream plan is to be able to grant authorizations to groups/roles, e.g. 'power_user_r' - with that you can just add users to that role and you will have the authorization that way. Ditto for a 'guest_r' role that wouldn't be able to authenticate to gain any authorizations (this is what guest accounts would use; think KIOSK use).

Whether it's called "power users" and whether it's going to be implemented via UNIX group membership is still an open question. I've been talking to Jon McCann about a new user management UI tool (including a backend) that will be able to support all this. But all this is up in the air right now; hoping to have parts of it ready for 2.24.

I wonder why there are multiple forms of this dialog at all.  Why not always use the list-box form, with the appropriate required user(s) shown in the dialog?  Wouldn't that make much more sense from a usability perspective?

If I might also make a suggestion about the text, the passive voice in the wording also makes it more difficult to read.  The following text would work better:

'An application is attempting to perform an action that requires privileges.  Please authenticate as one of the following users to perform this action.'

Then the list box could feature users in whichever group/role is appropriate.  If none of this makes sense in the future use case, then text pointing to the right tool probably would, a la:

'To authorize this action, add your user account to the "%s" group using the <FOOBAR> tool.  You may need to contact an administrator for this authorization.'

This now seems fixed, because the password field includes the account name in its label. However, I think a more elegant way of fixing it would be to improve the layout: if the account menu was left-aligned with the password field, it would be more obvious that the password you need to enter is the password for the account selected immediately above.

See https://bugzilla.gnome.org/show_bug.cgi?id=598770#c3

policykit-gnome is not under active development anymore.
Its codebase has been archived:
https://gitlab.gnome.org/Archive/policykit-gnome/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather reactivate the project
to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the
responsibility for active development again.