Bug 444101 - changing timezone of international clock requires wrong password
changing timezone of international clock requires wrong password
Product: Fedora
Classification: Fedora
Component: PolicyKit-gnome (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
Reported: 2008-04-24 20:05 EDT by John Poelstra
Modified: 2013-03-05 22:55 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-28 14:11:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Poelstra 2008-04-24 20:05:08 EDT
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'

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):

How reproducible:

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.
Comment 1 John Poelstra 2008-04-24 20:08:58 EDT
Bug for AVC errors is: https://bugzilla.redhat.com/show_bug.cgi?id=444102
Comment 2 Matthias Clasen 2008-04-27 18:32:02 EDT
> 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 ?
Comment 3 John Poelstra 2008-04-28 08:31:06 EDT
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.  :-)
Comment 4 Matthias Clasen 2008-04-28 10:34:05 EDT
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.
Comment 5 David Zeuthen 2008-04-28 13:33:05 EDT
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


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.
Comment 6 Jesse Keating 2008-04-28 13:48:12 EDT
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?
Comment 7 Paul W. Frields 2008-04-28 13:51:17 EDT
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.'

Comment 8 Paul W. Frields 2008-04-28 13:57:05 EDT
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?
Comment 9 John Poelstra 2008-04-28 13:58:16 EDT
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? :-) 
Comment 10 David Zeuthen 2008-04-28 14:11:37 EDT
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)


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.

Note You need to log in before you can comment on or make changes to this bug.