Description of problem: After add an additional clock to to the clock applet mousing over the the right side of the new clock area causes a "set" button to appear. Clicking on the 'set' button results in an 'authorization' dialog appearing. This appears to be the standard dialog that pops up for other applications which require 'root' authorization. The root password does not work. Instead the regular user's password (who is already logged into the system) works. This seems like really unusual behaviour. Is this consistent with upstream? Version-Release number of selected component (if applicable): gnome-panel-2.22.1.2-6.fc9.x86_64 How reproducible: 100% Additional info: Once you figure out that you need to supply your regular password and NOT the root password, you get three AVC errors. I will file that bug shortly.
Bug for AVC errors is: https://bugzilla.redhat.com/show_bug.cgi?id=444102
> Instead the regular user's password (who is already logged into the system) > works. This seems like really unusual behaviour. Is this consistent with > upstream ? PolicyKit can be configured to require admin authentication or just user authenticaiton (or no authentication at all) before allowing a privileged action to proceed. Do you think changing the timezone should require root ?
I'm not sure what the required level of authorization should be to change the timezone. I believe system-config-date has always required root to change the timezone so we could argue that it should not change or others could argue that it has always been too restrictive and unnecessary. I would like Steve Grubb's input here (added to CC) From my perspective, the part I think most needs to be fixed is being SPECIFIC about which user's password you are requesting. Simply popping up a dialogue requesting "authentication" when traditionally the answer has been the root password and changing that behaviour to be the password for a user that has already logged and been "authenticated" will drive users (and me) crazy. :-)
The point about requiring authentication here is ensure that this is a user-initiated action, not something done by a program behind the users back. I agree that the wording of the dialog should probably include the user to authenticate as.
This appears to be a PolicyKit-gnome bug so I'm taking it. FWIW, if the root password is needed, the dialogs are very clear about it http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html so I can't really agree this is a bug. So I'm closing this bug. Anyway, I think the confusion here (whether it's the users own password or the root password), is largely just an occupational illness from the exposure of systems where the only way to elevate was using such a weird thing as the root password. Fact of the matter (according to user studies) is that it just doesn't make sense for normal desktop users to keep remembering more than one password. That's why a lot of OS's (Ubuntu, OS X) simply disable the root account and put one or more users in the 'wheel' group. JFYI there are plans to do similar things for the desktop spin of F10 or F11 and PolicyKit already supports this (see the screenshots near the text "... and PolicyKit is configured to use the UNIX wheel group for this..." in the link above). Just need to hash out some details.
I still think it's pretty lame that we're just supposed to "know" that it's our own password being prompted for, and not somebody elses. Is it really that much of a big deal to clearly indicate that it's asking for /your/ password?
The passive voice used in the dialog boxes results in the language being more easily confused by the user. The following text might decrease those odds: 'An application is attempting to perform an action that requires privileges. Please authenticate as user "%s" to perform this action.' 'An application is attempting to perform an action that requires privileges. Please authenticate as the super-user to perform this action.' 'An application is attempting to perform an action that requires privileges. Please authenticate as one of the following users to perform this action.'
Actually, thinking about it a little more makes me ask 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?
It also says an operation is requested to be performed that requires PRIVILEGES which implies it is asking for something above and beyond what it already has. Privileges is most often understood as 'root'. Some of the examples show the user's name as part of the authorization request. Why can't we use one of those and why can't we help make this easy for people vs. assuming most people have learned incorrectly from all the past systems they have used? :-)
First, I still think you guys are way too concerned about users already knowing who 'root' is vs. the huge amount of users that hopefully never will learn about such a thing. But, just FWIW, you guys are not alone with this; here's a bug report from another (UNIX programmer of course) http://bugzilla.gnome.org/show_bug.cgi?id=529195 Second, I don't think the RH bugzilla is the appropriate place to discuss HIC and what the user experience should be when there's an upstream bug tracker for this already at gnome.org. Please take your input there (for example that bug I quoted above) and I'd be happy to discuss HIC / review patches there. Third, it's way too late in the game to change this as it would break translations. Closing as UPSTREAM. Take your suggestions there. Thanks.