Description of problem: I set my password in my keyring to be empty so auto-login works. Now during boot it asks for my encryption password and I mistyped it. I got prompted again so I type in the correct password and it boots. I reboot a second time and enter the correct encryption password the first time so it doesn't prompt again. Now when the login happens I get a password prompt for the keyring and the password was the incorrect password I typed the first time. I got and change it, and after the next reboot it has changed from empty to my encryption password. At some point I type in an incorrect password again and the keyring becomes locked and I have no idea what the incorrect password that I typed was and my keyring is unlockable. Why the heck is the encryption password prompt messing with the GNOME keyring password? I don't think it happened this way in Fedora 24. Version-Release number of selected component (if applicable): gnome-keyring-3.20.0-1.fc25.x86_64 How reproducible: Everytime it changes. Steps to Reproduce: 1. Enable autologin 2. Enable encryption 3. Set keyring password to empty 4. Give incorrect encryption password 5. Reboot 6. Give correct encryption password 7. Prompted for incorrect password Actual results: The password for the keyring changes to match the first typed encryption password. Expected results: I expect the password to remain unchanged.
I was able to use john the ripper (jumbo edition), which also includes keyring2john, to crack my GNOME keyring password. I started with a wordlist that contained my known password and let it do it's simple password rules to try variations. It only took a few seconds to find the password. I did a few experiments with it now unlocked and I figured out how I got locked out. If you type an incorrect encryption password the first time (despite entering it X times after for each of the X encrypted volumes), it will fail to unlock the keyring when auto-logged in. It then prompts you for your password which you enter to unlock it and then it immediately changes the password to the incorrect password. Next boot it now has the incorrect password so it doesn't unlock automatically and prompts you for it, except this time you don't know what to type it. I guess the best I can do for now is to try and disable this passing of passwords and go back to the old schema of having an empty password on the keyring. I personally am not concerned with that since the entire hard drive is already encrypted.
I worked around this problem by effectively removing /usr/lib64/security/pam_gnome_keyring.so. You can't just remove the gnome-keyring-pam package because a bunch of stuff depends on it and just removing the file will become a hidden problem when the package updates. So I used fakeprovides (from https://github.com/larsks/fakeprovide) to create a fake package that provides gnome-keyring-pam then I was able to remove the original gnome-keyring-pam and hence the file. It seems to me this is more a problem with plymouth actually, passing the encryption password all the way through gdm to the user session.
Yes, I have the same problem: I have encrypted my home directory with luks and systemd/plymouth asks me every boot to unlock it. Since I don't want to type my password twice my user logs in automatically and the keyring has its password removed. Indeed when I input a wrong luks password (it is quite lengthy on a laptop with too small keys so that happens way too often) the keyring password will subsequently be set to the first, wrongfully entered luks password. When I recreate a new keyring and only add an IMAP account to it via Evolution the password is not changed/it doesn't lock up. The keyring only seems to lock up after I also add my Gmail account to it via GOA. After that the keyring's password doesn't seem to change any more. Possibly GOA changes the keyring's password? It would be very strange though because it would mean that the wrong password is also kept in memory and passed to the user's session for some reason. Yet, this really seems to be what is happening because I tested this with a wrong password very distinct from my actual password and unless I use that wrong password I wasn't able to unlock the keyring after the password changed. Maybe a simpler work around is to first enter an empty password and then the real luks password during boot?
When gdm autologin is enabled it looks like the first entered password in systemd-ask-password-plymouth always ends up in the memory of the unprivileged gnome-keyring-daemon process at the memory location where otherwise the normal login password would be stored to unlock the keyring. If the first password entered is empty the same is true for the value in the keyring process and if gdm autologin is disabled no luks password is leaked (at least to the keyring process). During testing this, gnome-keyring sometimes changed the password on the keyring but not always and I don't think it did it completely on its own (I possibly manually locked the keyring via seahorse after which I could still unlock it since I knew the password, but I'm not sure it would always change the password when locking the keyring with a wrong password in memory). So there appear to be two bugs: - potentially full system encryption credentials are inadvertently passed by systemd/gdm to the user's sessions where normally the user password is expected. - when the user somehow managed to change the password in the memory of the gnome-keyring-daemon process it sometimes will inadvertently (re-)encrypt the keyring using the wrong password thus making it inaccessible.
@Christian, I was reporting the issue originally because of the inconvenience of having it change my keyring password to some incorrectly typed LUKS password. You're point of anyone listening in on the PAM conversation during login being able to get your LUKS password unencrypted starts to scare me now. I suppose that was true before when making the transition from the GDM login screen to the user session, but I personally feel my LUKS password is more important and that's why it's longer and more complex on my systems. You would hope your system is secure an no one unexpected is listening in during login, but I'd rather it just not leak that information in the first place and even better not have the unintended consequences :-)
I agree, I think a gdm developer should look into this. One would expect a luks password only be used by the kernel to handle encrypted volumes. Maybe what gdm does is normally used for handling per-user encrypted volumes/containers? Seems quite convoluted to only do that for autologins. In my case this still would be quite nuts because my whole /home partition is a single encrypted volume, not per user. My user should never get that key nor should any other user-space code after it has been entered. I would expect the key to only be supplied to a kernel-space facility (presumably dm-crypt) and nothing else. I've been looking at https://github.com/GNOME/gnome-keyring/blob/master/pam/gkr-pam-module.c but I can't pin down where getting the password lookup and auto_start go wrong. In the mean time my keyring has been locked again without an option to unlock it afterwards, so simply first entering an empty password probably doesn't work properly. There appears to be a way to reinitialise the keyring daemon so that the luks password is gone from its memory (gnome-keyring-daemon --replace --daemonize) but this causes the shell to lose track of the keyring daemon (at least Gmail stays inaccessible).
My workaround for now was to just disable the whole thing by replacing the pam module (aka the rpm) with a dummy package. You probably already saw that in my comments above. Obviously that is not the fix just a workaround.
I was a bit hesitative to install an rpm for this that possibly meant disabling autologin altogether, but reading more carefully it looks it only disables the automatic unlocking of the keyring? But I think I found a similar method that doesn't require forceful removal or replacement of the gnome-keyring-pam package: simply comment out the 'session optional pam_gnome_keyring.so autostart' line in /etc/pam.d/gdm-autologin. I expect this results in the exact same thing, with most likely the side effect that during regular logins the login password can still be passed to the user (which is not of much use when the keyring has no password set but might be useful when working with other user profiles which do have a protected keyring).
You are right. I just installed a new dummy package replacing the existing package which effectively removes the library file. I should have probably commented out that line in /etc/pam.d/gdm-autologin instead, but I guess I went to the extreme to make it easy to disable. Thinking about the change you just made, if you autologin in why would you ever want gnome-keyring-pam to be used? You never typed in a password so what would it pass through other than the wrong thing (LUKS password). I guess the fix for this bug is to remove that line. I don't have Fedora 24 installed anymore, but I guess I could boot a live CD or look at the git history for the package and see if was added recently.
I think the file /etc/pam.d/gdm-autologin was changed and the following line was added near the top: -auth optional pam_gnome_keyring.so I'm not sure if it's really new but I tested this issue again today with gdm-3.22.3 (which fixed an autologin issue I had), but the problem is still there.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 EOL if it remains open with a Fedora 'version' of '25'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm using F33 and still have this same problem. Any progress on this subject?