|
Bugzilla – Full Text Bug Listing |
| Summary: | Keyring not unlocked at login | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | James Ogley <riggwelter> |
| Component: | GNOME | Assignee: | E-mail List <gnome-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | David, dimstar, fcrozat, mark.gonnelly, meissner, vuntz |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
James Ogley
2010-07-15 21:04:56 UTC
Do you use autologin? I don't. I have another machine with it installed where it works, this machine differs in two ways: 1) It's i586 not x86_64. 2) It's a new user and $HOME, here it's an existing $HOME. Will create a new user on the machine where it's not working to see if it happens with that user so we know if it's the architecture or the existing $HOME. It's working fine for me on i586 with an old user... Do you have any message in .xsession-errors or /var/log/messages around your login time that appear related? Okay with the new user on both i586 and x86_64 I did the following: * Login * Provide password for wireless network Then, this is what happened: i586: Nothing! Password apparently saved. Logged out and in again and it worked perfectly. x86_64: Prompted to create a new keyring "Default". Provided the same password for it as my login password. Logged out and in again and was told that network manager was trying to access the "Default" keyring but it was locked and I had to provide the password. Both these are different to with a pre-existing $HOME (on x86_64) where when I'm logged in, I'm told that my "login" keyring could not be unlocked and I have to provide the password before nm-applet will connect to the wireless. Only relevant things in .xsession-errors with the existing user is: GNOME_KEYRING_CONTROL=/tmp/keyring-MW9tmL GNOME_KEYRING_PID=12905 GNOME_KEYRING_CONTROL=/tmp/keyring-MW9tmL GNOME_KEYRING_CONTROL=/tmp/keyring-MW9tmL And in /var/log/messages (obscuring anything that could be sensitive data): Jul 16 08:28:44 capyabara gnome-keyring-daemon[12905]: PROMPT INPUT:#012#012[prompt]#012title=Unlock Login Keyring#012primary=Enter password for to unlock your login keyring#012secondary=The login keyring did not get unlocked when you logged into your computer.#012window-id=#012#012[visibility]#012name_area=false#012confirm_area=false#012password_area=true#012#012[transport]#012public=LONGSEQUENCEOFCHARACTERS#012base=02#012 Jul 16 08:28:45 capyabara gnome-keyring-prompt: could not grab keyboard: 3 Jul 16 08:28:45 capyabara gnome-keyring-prompt: could not grab keyboard: 3 16 08:49:47 capyabara gnome-keyring-daemon[12905]: PROMPT OUTPUT:#012#012[transport]#012public=ANOTHERLONGSEQUENCE#012#012[password]#012parameter=CHARS#012value=CHARS#012#012[unlock-options]#012unlock-auto=false#012unlock-timeout=0#012unlock-idle=0#012#012[details]#012expanded=false#012#012[prompt]#012response=ok#012 Jul 16 08:49:48 capyabara gnome-keyring-daemon[12905]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Here's what was in messages with the new user on x86_64: gnome-keyring-daemon[11150]: PROMPT INPUT:#012#012[prompt]#012title=New Keyring Password#012primary=Choose password for new keyring#012secondary=An application wants to create a new keyring called 'Default'. Choose the password you want to use for it.#012window-id=#012#012[visibility]#012password_area=true#012confirm_area=true#012#012[transport]#012public=STUFF#012prime=STUFF#012base=02#012 Jul 16 08:27:13 capyabara gnome-keyring-prompt: could not grab keyboard: 3 Jul 16 08:27:13 capyabara gnome-keyring-prompt: could not grab keyboard: 3 Jul 16 08:27:29 capyabara gnome-keyring-daemon[11150]: PROMPT OUTPUT:#012#012[transport]#012public=FOOBAR#012#012[password]#012parameter=FOOBAR#012value=FOOBAR#012#012[confirm]#012parameter=FOOBAR#012value=FOOBAR#012#012[unlock-options]#012unlock-auto=false#012unlock-timeout=0#012unlock-idle=0#012#012[details]#012expanded=false#012#012[prompt]#012response=ok#012 Jul 16 08:28:02 capyabara gnome-keyring-daemon[12074]: PROMPT INPUT:#012#012[prompt]#012title=Unlock Keyring#012primary=Enter password for keyring 'Default' to unlock#012secondary=An application wants access to the keyring 'Default', but it is locked#012window-id=#012#012[visibility]#012name_area=false#012confirm_area=false#012details_area=true#012password_area=true#012lock_area=true#012options_area=true#012auto_unlock_check=false#012#012[unlock-options]#012unlock-auto=false#012unlock-idle=0#012unlock-timeout=0#012#012[transport]#012public=STUFF#012prime=STUFF#012base=02#012 Jul 16 08:28:17 capyabara gnome-keyring-daemon[12074]: PROMPT OUTPUT:#012#012[transport]#012public=STUFF#012#012[password]#012parameter=STUFF#012#012[unlock-options]#012unlock-auto=false#012unlock-timeout=0#012unlock-idle=0#012#012[details]#012expanded=true#012#012[prompt]#012response=ok#012 Are there any lines with gkr-pam in your log? Also, I'm assuming both machines are using gdm. If it's not the case, then that could explain it :-) Also seeing this on x86_64 - entirely new install and new user account. This seems fixed in G:S:2.30. I didn't think anything had changed though. Sorry, now I see, it's upgraded to 2.30.3 and I think this may be the change that mattered: + Use proper locking for secure memory in daemon. I'm surprised this change matters, but the only difference between our package in 11.3 and 2.30.3 is this change and "Fix possible threading race condition in gp11" (the other ones are patched in). Mark: can you install the gnome-keyring, libgcr0, libgp11-0 and libgp11-modules packages (and only those packages) from GNOME:STABLE:2.30 and see if it helps? (In reply to comment #10) > Mark: can you install the gnome-keyring, libgcr0, libgp11-0 and libgp11-modules > packages (and only those packages) from GNOME:STABLE:2.30 and see if it helps? I can't install just those packages owing to dependencies. Force them or let them update whatever they want? Hrm, not sure. Which dependencies are needed? (In reply to comment #12) > Hrm, not sure. Which dependencies are needed? triona:/home/mark/Desktop # rpm -Uvh gnome-keyring-2.30.3-1.2.x86_64.rpm error: Failed dependencies: gnome-keyring-lang = 2.30.3 is needed by gnome-keyring-2.30.3-1.2.x86_64 libgp11-modules = 2.30.3 is needed by gnome-keyring-2.30.3-1.2.x86_64 gnome-keyring = 2.30.1 is needed by (installed) gnome-keyring-pam-2.30.1-2.11.x86_64 Just install those packages too, then -- they're all gnome-keyring related. Installed those packages. When I logged in I was prompted again to unlock the keyring but there was a checkbox to enable automatic unlocking in future. Logging out and back in again, this seems to work fine. This may just have been user error but I don't remember seeing that checkbox before. I confirm upgrading gnome-keyring to 2.30.3 fixed the issue of wrong keyring being unlocked at login by pam module. Maintenance team: can we do an update to gnome-keyring 2.30.3? It fixes the issue. See osc rdiff openSUSE:11.3 gnome-keyring GNOME:STABLE:2.30. FWIW, I'm not completely sure why it fixes the issue since we have a patch that should contain all those fixes already :/ Yes, I think we can do it. Upgrade only contains bugfixes. So +1 seems like bug 574670 . There is no gnome-keyring settings settings in /etc/pam.d/common-session with default installation. We have some scripts in rpm, so that reinstalling can fix the bug. The problem is that why the settings is missing? (In reply to comment #19) > seems like bug 574670 . > > There is no gnome-keyring settings settings in /etc/pam.d/common-session with > default installation. > > We have some scripts in rpm, so that reinstalling can fix the bug. > > The problem is that why the settings is missing? Ah, interesting. So the call to "/usr/sbin/pam-config -a --gnome_keyring --gnome_keyring-auto_start --gnome_keyring-only_if=gdm,lxdm" in the %post of gnome-keyring-pam is only what is needed. That would not be a GNOME bug, then, if something else changes the pam config and removes gnome-keyring from there. Hrm, I just did an install from the 11.3 livecd, and I do have the keyring pam module in /etc/pam.d/common-session. So maybe something else changes the file after installation, at some point :/ Note to self & maintenance team: if/when we do an update for this, we should take bug 635743 too in the update. interesting would be to find out what did not work during initial upgrade. I upgraded via factory and my pam.d/common-session has the above entry. can you ls -l /etc/pam.d/common-session* and see if there is anything visible on who might have touched it? hmm, just got the issue on a new 11.3 install (from GNOME livecd) and I confirm I had to run %post from gnome-keyring-pam to fix it but only in non autologin mode. In autologin mode, bug is not fixed, due to gnome bug #621506 where you need to change keyring password to empty password (which is not great from security PoV). no info required from maintenance team? Sorry, this bug did not get the attention it deserved. Not likely, you have already upgraded to newer versions of openSUSE, which had a lot more bug fixes. As openSUSE 11.3 is no longer maintained (for a long time already) and I can't seem to reproduce anything similar in openSUSE 12.1 / 12.2 RC, I close the bug as 'wontfix'. Should you be able to reproduce this issue on a newer openSUSE version, please feel to report it again. |