Version-Release number of selected component (if applicable): gnome-keyring-pam-2.28.2-2.fc12.x86_64 gnome-python2-gnomekeyring-2.28.0-2.fc12.x86_64 gnome-keyring-2.28.2-2.fc12.x86_64 seahorse-2.28.1-2.fc12.x86_64 How reproducible: unknown Steps to Reproduce: 1. create a user & store some secrets in the default keyring 2. change the user's password with passwd while the user is logged into a desktop session 3. logout & login; the default keyring should refuse to be unlocked by either the old or the new password Additional info: Attempting to change the default keyring password using seahorse fails.
That seems to me like a duplicate of bug 559860 - can you please confirm this?
I don't think this is a dup of 559860. selinux reports no denials for this. I checked /var/log/secure and found: Feb 4 09:16:47 localhost passwd: pam_unix(passwd:chauthtok): password changed for dallan Feb 4 09:16:47 localhost passwd: gkr-pam: couldn't change password for 'login' keyring: 1 What's really puzzling is that the keyring doesn't unlock with either the old key or the new one, so it's not just a matter of not changing the password. Am I correct in thinking that the password for the default keyring should be the same as my login password? That's how I interpret the "How it Works" section of http://live.gnome.org/GnomeKeyring/Pam
I just tried and failed to reproduce this behavior. I also tried changing my password as root with passwd, which failed in the way I would expect, the password was changed, the keyring password was not changed and the old password was able to unlock the keyring.
If you run passwd as root, it cannot update your keyring password.
Matthias, yes, I know using passwd as root will fail, that's why I said it failed *as I would expect*, leaving the keyring password unchanged. The bug I filed is against a failure in which the keyring password was changed to something unknown when I ran passwd as my UID. However, since I cannot reproduce that behavior, I don't think there's much point in investigating further. If it happens again, of course, I'll update the bug.
I can reproduce it changing my user password using accountsdialog-0.6-3.fc13.x86_64 on f13. When log out and log in a dialog shows in evolution saying "Enter password for keyring 'default' to unlock", I enter my old password and it unlocks but then asks me for my pop password (that's another bug but not sure who's, because that pw was in the keyring before). While changing pw I hit bug 564069, so maybe it's related. It's an upgraded machine from f12. selinux-policy-3.7.19-15.fc13.noarch gnome-keyring-2.30.1-2.fc13.x86_64 libgnome-keyring-2.30.1-1.fc13.x86_64 /var/log/secure contains: May 12 22:16:47 endeavour passwd: pam_unix(passwd:chauthtok): password changed for ivan May 12 22:16:47 endeavour passwd: gkr-pam: couldn't change password on login keyring: gnome-keyring-daemon is not running /var/log/messages: May 12 22:16:47 endeavour gnome-keyring-daemon[1696]: couldn't create socket directory: Permission denied May 12 22:16:47 endeavour gnome-keyring-daemon[1696]: couldn't bind to control socket: /tmp/keyring-n5JFdp/control: No such file or directory May 12 22:16:50 endeavour setroubleshoot: SELinux está negando a /usr/bin/gnome-keyring-daemon el acceso "write" on /tmp. For complete SELinux messages. run sealert -l 554e6d69-4e65-4b23-b6d1-dfa7290fb572 May 12 22:19:49 endeavour : report: Bug Updated:A bug with your information already exists. Your account has been added to the CC list and your traceback added as a comment. Please add additional descriptive information to the following bug: https://bugzilla.redhat.com/578573 and .xsession-errors: GNOME_KEYRING_CONTROL=/tmp/keyring-lu6uGD GNOME_KEYRING_CONTROL=/tmp/keyring-lu6uGD SSH_AUTH_SOCK=/tmp/keyring-lu6uGD/ssh GNOME_KEYRING_CONTROL=/tmp/keyring-lu6uGD SSH_AUTH_SOCK=/tmp/keyring-lu6uGD/ssh
Hi Ivan, that's a different scenario from what I encountered. What I saw was that neither the old password nor the new password would unlock the keyring; it was totally inaccessible.
(In reply to comment #7) > Hi Ivan, that's a different scenario from what I encountered. What I saw was > that neither the old password nor the new password would unlock the keyring; it > was totally inaccessible. Ups, I misread it, thanks for the reply Dave! So, I guess I should file a new bug, but I'm not sure if against accountsdialog or gnome-keyring?
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I haven't experienced this problem again, and since there's not enough information to debug it, I'm closing the BZ.