I have upgraded my system from Mageia 4 to 5. Now, I have to type my password twice, as the gnome keyring is not unlocked. I'm using gdm and the gnome3 environment. I have tried to change the password using passwd, no change. Reproducible: Steps to Reproduce:
I have the same issue. after migrating from Mageia3 to Mageia5. We use Gnome-keyring to automatically unlock our samba based printing system. The printing system ask for a password, but when we check "Remember the password", it is stored in a new keyring, not in the login keyring, because it hasn't been unlocked at login.
CC: (none) => Damien.Genthial
Thanks for reporting this bug. Unfortunately our maintainers database knows no maintainer for gnome-keyring, although Olav Vitters might be the de facto one. Olav, are you maintaining this package? If so please assign the bug report to yourself and add yourself in the maintainers database. There's also gnome-keyring-sharp.
CC: (none) => olav, tarakbumba
CC: (none) => davy.defaud
I have been running into this too ever since I upgraded to Mageia 5. So I finally dug around a bit and found the issue: pam_gnome_keyring.so is not being run due to short-circuiting in /etc/pam.d/gdm . The fix is as follows: --- /etc/pam.d/gdm.rpmorig 2015-05-28 11:59:07.000000000 -0700 +++ /etc/pam.d/gdm 2015-10-10 19:22:16.060131976 -0700 @@ -1,7 +1,7 @@ #%PAM-1.0 auth required pam_env.so auth sufficient pam_succeed_if.so user ingroup nopasswdlogin -auth include system-auth +auth substack system-auth auth optional pam_gnome_keyring.so account include system-auth password include system-auth This exact scenario is described in the "Advanced Configuration" section of https://wiki.gnome.org/Projects/GnomeKeyring/Pam#Advanced_configuration . Interestingly enough, Mageia 4 had "substack", and I have no idea why this was changed; also, gdm-pin is correct here.
CC: (none) => mageia824
Colin, could you confirm?
CC: (none) => mageia
I also get this but I assumed it was because I had various options disabled. I suspect it's a simple matter of updating the pam.d file to unlock the key ring properly. I suspect the fix is as above. Our merging of the pam files is always tricky but this seems sensible to be (with my limited pam knowledge).
I can confirm that switching the gdm auth from "include system-auth" to "substack system-auth" worked for me. It wouldn't be hard to quickly provide a pam update with a so easy fix. ;-)
It works also for me ! Many thanks !
It solved also the problem in my PC after the migration from Mageia 4. Many thanks!!
CC: (none) => carlo.gozzi
*** Bug 17273 has been marked as a duplicate of this bug. ***
CC: (none) => guillomovitch
Assigning to gnome maintainer group. Easy fix included in comments.
Keywords: (none) => PATCHAssignee: bugsquad => gnome
CC: olav => (none)
OK, the good news is that it should work OK in Cauldron for future mga6 as we now uses /etc/pam.d/gdm-password and there's no more /etc/pam.d/gdm
CC: (none) => thierry.vignaud
(In reply to Thierry Vignaud from comment #11) > OK, the good news is that it should work OK in Cauldron for future mga6 as > we now uses /etc/pam.d/gdm-password and there's no more /etc/pam.d/gdm Even after an upgrade from Mageia 5? The file will be removed?
>Even after an upgrade from Mageia 5? The file will be removed? As any other configuration file, unless a specific behavior has been implemented: removed if not modified, renamed as gdm-password.rpmsave otherwise.
I have no clue about PAM. I don't want to apply something without understanding anything. Setting needhelp.
Keywords: (none) => NEEDHELPCC: (none) => olav
'include' keyword implies direct return to the caller application if any included directive marked as 'sufficient' succeed, hence bypassing the call to pam_gnome_keyring, whereas 'substack' force evaluation of remaining directives, even if the included ones succeed. In our case, we have: 1) auth required pam_env.so 2) auth sufficient pam_succeed_if.so user ingroup nopasswdlogin 3) auth include system-auth 3.1) auth required pam_env.so 3.2) auth sufficient pam_unix.so try_first_pass likeauth nullok 3.3) auth required pam_deny.so 4) auth optional pam_gnome_keyring.so 5) auth include postlogin In this scenario, a success for directive 3.2 will result in directives 3.3, 4 and 5 being ignored. 1) auth required pam_env.so 2) auth sufficient pam_succeed_if.so user ingroup nopasswdlogin 3) auth substack system-auth 3.1) auth required pam_env.so 3.2) auth sufficient pam_unix.so try_first_pass likeauth nullok 3.3) auth required pam_deny.so 4) auth optional pam_gnome_keyring.so 5) auth include postlogin In this scenario, a success for directive 3.2 will result in directives 3.3 only being ignored. Another explanation is available here: https://wiki.gnome.org/Projects/GnomeKeyring/Pam#Advanced_configuration
Closing as OLD, because I assume this isn't an issue in a maintained version of Mageia (Mageia 6 and cauldron), because of comment #11 : > OK, the good news is that it should work OK in Cauldron for future mga6 as > we now uses /etc/pam.d/gdm-password and there's no more /etc/pam.d/gdm @ Götz Please reopen this report and change its "Version:" at the top left to "6", if the same bug still exists in Mageia 6. ==> If you didn't reset your password after february 2018, then you'll need to reset it here https://identity.mageia.org/forgot_password to be able to log in and comment in this report. <==
CC: (none) => marja11Resolution: (none) => OLDStatus: NEW => RESOLVED