pop-os
The login keyring doesn't unlock for some apps
I'm unsure if this is an issue with the greeter, but some apps request login keyring to get unlocked despite logging in properly through cosmic-greeter (in my case it was the Minecraft flatpak, issue doesn't seem to occur with other flatpaks).
This should be handled by the pam_gnome_keyring module, which depending on your distro may or may not be included in the default login-pam profile we are using atm. (See https://wiki.archlinux.org/title/GNOME/Keyring#Using_the_keyring on how to change that.)
The correct fix however would be to create our own PAM config for cosmic-greeter that does setup the keyring automatically.
I understand the issue to be "login keyring is not unlocked upon login" which symptom is all apps are unable to use the keyring. You can diagnose this in PopOS 24.04 w/ Cosmic by logging in and running seahorse (or search "keyring" in app launcher) and observe the "Login" keyring is locked.
@Kartonrealista what version of cosmic-greeter do you have and did you reboot after updating?
@Kartonrealista what version of cosmic-greeter do you have and did you reboot after updating?
It works after a reboot, I thought it was enough to log out after updating.
I still seem to be running into this issue on Fedora. I even uncommented the needed lines in the /etc/pam.d/cosmic-greeter as per https://wiki.archlinux.org/title/GNOME/Keyring#Using_the_keyring.
From what I understand is this should be working by default at this point. Is there anything else I should check?
@mrust1219 does your /etc/pam.d/cosmic-greeter look like the one in this repository? https://github.com/pop-os/cosmic-greeter/blob/39de7578466e60a2a744144465f78de8caaceffa/debian/cosmic-greeter.pam
@jokeyrhyme
The one generated by Fedora looks like this by default:
#%PAM-1.0 auth substack system-auth -auth optional pam_gnome_keyring.so -auth optional pam_kwallet5.so -auth optional pam_kwallet.so auth include postlogin
account required pam_sepermit.so account required pam_nologin.so account include system-auth
password include system-auth
session required pam_selinux.so close session required pam_loginuid.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session include system-auth -session optional pam_gnome_keyring.so auto_start -session optional pam_kwallet5.so auto_start -session optional pam_kwallet.so auto_start session include postlogin
To me, this looks correct. Gnome keyring is definitely installed as well.
I thought the "-" were comments at first, but those just mean pam won't log an error message.
However it still prompts for the password upon launching something like Brave Browser, which requires the keyring to be unlocked
@mrust1219 does the greetd.toml that is used by your cosmic-greeter.service set service=cosmic-greeter ? https://github.com/pop-os/cosmic-greeter/blob/39de7578466e60a2a744144465f78de8caaceffa/cosmic-greeter.toml#L5
I think that's how greetd is told which pam.d service to use
I still have this issue.
I'm on ublue-os/cosmic
So I guess it's a similar setup to the one of @mrust1219
I'm using the latest alpha.5.1 of cosmic.
The cosmic-greeter package I'm using is cosmic-greeter-1.0.0~alpha.5.1^git20250114.116ef79-1.fc41.x86_64
So I got really stuck on this issue. @jokeyrhyme gave me the clue I needed; thanks! Apparently I 'temporarily' fixed the issue by setting service to login, which then points to /etc/pam.d/login.
The real solution was to create /etc/pam.d/cosmic-greeter and fill it with whatever you need for your use-case.
In my case the Arch Linux package forgot to vendor this file. I've created an issue for it on the Arch GitLab.
