glibc-2.39_4: gnome-keyring no longer getting unlocked at login

[gc-user]

Is this a new report?

Yes

System Info

oid 6.6.41_1 x86_64 GenuineIntel uptodate hold rrmDDDDDDFFFFFFFFFF

Package(s) Affected

glibc-2.39_4.x86_64

Does a report exist for this bug with the project's home (upstream) and/or another distro?

Not that I could find (for void).

Expected behaviour

Usually gnome-keying gets unlocked at login so that seahorse or chrome don't need to ask for password to access the keyring or what's inside it.

Actual behaviour

After updating from glibc-2.39_3.x86_64 to glibc-2.39_4.x86_64, chrome based browsers ask for password at start and seahorse also needs the password to open the keyring.

Downgrading to glibc-2.39_3.x86_64 "fixes" this issue.

Maybe some other package needs an update to go along with glibc-2.39_4.x86_64 to not have this issue come up. E.g. some pam or libcrypt package.

Steps to reproduce

1. Update to glibc-2.39_4.x86_64.
2. Use chrome-based browser, seahorse or any other program that needs / wants access to gnome-keyring (provided that one is used to manage passwords).
3. See that those programs no longer have access to the keyring without having to put in the password. I.e. notice the keyring no longer geting unlocked at / with login.

[gc-user]

The issue seems to be able to be avoided if libgnome-keyring is installed.

Thus the title could also be "Update to glibc-2.39_4 makes libgnome-keyring to be installed necessary in order for gnome-keyring getting unlocked at login, when before that update libgnome-keyring was not needed".

So, not sure if that was an intended "improvement" in glibc or just accidentally.

[xhyrom]

I've came across this issue and fixed it thanks to https://wiki.gentoo.org/wiki/LightDM#Unlock_GNOME_Keyring

modifying /etc/pam.d/lighteco seems to work.

#%PAM-1.0

# Block login if they are globally disabled
auth      required pam_nologin.so

# Load environment from /etc/environment and ~/.pam_environment
auth      required pam_env.so

# Use /etc/passwd and /etc/shadow for passwords
auth      required pam_unix.so

+ # keyring
+ auth     optional        pam_gnome_keyring.so

# Check account is active, change password if required
account   required pam_unix.so

# Allow password to be changed
password  required pam_unix.so

# Setup session
session   required pam_unix.so
-session   optional pam_elogind.so                   # ignore this diff, keep it
-session optional pam_ck_connector.so nox11 # ignore this diff, keep it

+ # keyring
+ session  optional        pam_gnome_keyring.so auto_start

session required /lib/security/pam_limits.so

but @gc-user's approach by installing libgnome-keyring is probably also a way

[ahesford]

Installing libgnome-keyring is not the rigth fix, because that package has been removed. This should also have nothing to do with glibc.

The right fix is modifying the appropriate PAM configuration for whatever you are using to log in.

[gc-user]

On my system, those setting were always necessary, i.e. not a new requirement for glibc-2.39_4.x86_64 (on my system, at least).

[classabbyamp]

the only thing different between _3 and _4 is 4c973e6

[gc-user]

Well "should" and reality sometimes don't align.
If I downgrade to "_3" and it works, when with "_4" it doesn't, something's wrong. I checked the diff file and also saw that there shouldn't be any reason for it not to work, but it is like it is.

I only tested libgnome-keyring (which still is available from the void repos) because I came across it being a solution in some other (maybe Mint Linux?) forum. I wasn't happy it worked... :-) because I didn't want this to be "the fix"...

[xhyrom]

Well "should" and reality sometimes don't align. If I downgrade to "_3" and it works, when with "_4" it doesn't, something's wrong. I checked the diff file and also saw that there shouldn't be any reason for it not to work, but it is like it is.

I only tested libgnome-keyring (which still is available from the void repos) because I came across it being a solution in some other (maybe Mint Linux?) forum. I wasn't happy it worked... :-) because I didn't want this to be "the fix"...

I looked into many forums including arch, gentoo and also reddit and the gentoo wiki worked for me as I said earlier.

[gc-user]

To phrase my first reply differently to express the same:

The /etc/pam.d/lightdm file on my system has those entries since 2020.

[xhyrom]

To phrase my first reply differently to express the same:

The /etc/pam.d/lightdm file on my system has those entries since 2020.

Sorry, I missed it. Do you also have those entries in /etc/pam.d/login? Well it's probably not required but I have these in those two places.

[gc-user]

I did some more testing.
I removed libgnome-keyring. Surprisingly (or not), the keyring still gets unlocked at login now. Even with the "_4" glibc. As one would expect.
But it's still mystery to my, why from around the 19th of July until yesterday that wasn't the case and a chrome-based browser asked for the password at start after a new boot.

I'll keep watching this and digging should this re-appear.

There were some updates for other packages yesterday and today, but none that I would suspect to be involved in this issue from their names (and description in octo-xbps). I tested pkc11-helper (because it's descriptions it's apparently involved in cryptographic stuff, but I didn't expect it to be involved here - just grasping for something... :-)) by downgrading to the version before yesterday, but it didn't make a difference.

[gc-user]

To phrase my first reply differently to express the same:
The /etc/pam.d/lightdm file on my system has those entries since 2020.

Sorry, I missed it. Do you also have those entries in /etc/pam.d/login? Well it's probably not required but I have these in those two places.

Nope. But as it works as of today with going back to the previous state, I'll just keep watching the issue and test adding it to that file, too, should it re-appear to see what happens.
Thanks for the hint!