Description of problem: When trying to configure the system using user A, the system requires the password for user B to make changes. I am certain that this has nothing to do with passwd, but I have not idea what component it doing this, or how to figure that out. As Fedora modifies its desktop experience, it might be nice to have bugs for GUI elements rather than system components... Version-Release number of selected component (if applicable): ? How reproducible: Always happens, despite adding user A to the wheel group. (User B was originally created during or immediately after install) Steps to Reproduce: 1. Try to modify a system setting. 2. Fail because I do not have the other users password. 3. Actual results: Expected results: Additional info: Problem describe here: http://fedoraforum.org/forum/showthread.php?p=1483595#post1483595 Here is a link to another user having the same issue: http://www.yendis.org/Screenshot-1.png
This is by design - in the default install, members of the wheel group (if non-empty) are used for administrator authentication. If you want, you can configure the desired behavior by dropping a .conf file in /etc/polkit-1/localauthority.conf.d directory. For more details see the "ADMINISTRATOR AUTHENTICATION" and "EXAMPLES" parts of the pklocalauthority(8) man page: $ man pklocalauthority which is also available online here http://hal.freedesktop.org/docs/polkit/pklocalauthority.8.html Closing as NOTABUG.
Both my user and the other user are in the wheel group. So I have the "right" to do this, and it is still trying to leverage the other wheel group user. This is still a bug.
(In reply to comment #2) > Both my user and the other user are in the wheel group. I didn't realize both users were in the wheel group - that's not how I read comment 0. > So I have the "right" to do this, and it is still trying to leverage the other > wheel group user. > > This is still a bug. It's not a bug, it's is a well-known limitation of gnome-shell's authentication agent so I'm reassigning to that component. There's an upstream bug about this problem, see https://bugzilla.gnome.org/show_bug.cgi?id=651547 where it was decided to never ask for the password of another user. So this bug can be closed UPSTREAM but I'm leaving that to the gnome-shell package maintainer. Note that this actually works for the textual authentication agent, e.g. [davidz@thinkpad ~]$ ssh bateman@localhost bateman@localhost's password: ******** <- bateman's password Last login: Wed Jan 4 10:16:09 2012 from localhost.localdomain [bateman@thinkpad ~]$ pkexec bash ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/bin/bash' as the super user Multiple identities can be used for authentication: 1. David Zeuthen (davidz) 2. Patrick Bateman (bateman) Choose identity to authenticate as (1-2): 1 Password: ******** <- davidz's password ==== AUTHENTICATION COMPLETE === [root@thinkpad ~]# exit
*** Bug 799480 has been marked as a duplicate of this bug. ***
I'm experiencing this same bug, in Fedora 16, 17 and 18 beta, and was about to file a report about it when I found this report. Most of the time, the alphabetically first user that is in the wheel group is being used, as can be seen in /var/log/secure where the authentication failure is logged. That is the case, even if the current user is in the wheel group (in which case entering his/her own password should be enough). Most of the time, the dialog window doesn't even mention which user is being used, and it is only afterwards that the authentication failure in the logs reveals, which user was being prompted for. Adding root to the wheen group or changing the order of the users in that group doesn't make a difference. So I consider this not fixed, and not just a known limitation, but a serious design flaw and a loss of functionality. Note that indeed it is a gnome interface issue; doing the exact same things in another desktop environment will work; the authentication window in those cases will contain a pull-down menu with users that are in the wheel group.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.