After switching from SDDM to plasma-login-manager, gnome-keyring now wins org.freedesktop.secrets instead of KWallet

Support KDE Plasma
1

Hey everyone,

I think I have worked out what is going on with a credential problem on my
system, but I would like a sanity check from someone who knows the packaging
before I change anything. Apologies if this is well known already.

System

  • Manjaro Linux, kernel 7.2.0-1-MANJARO
  • KDE Plasma 6.7.4, Wayland
  • plasma-login-manager 6.7.4-1, installed 2 September, replacing sddm
  • gnome-keyring 1:50.0-1, kwallet 6.29.0-1, kwallet-pam 6.7.4-1

The symptom

Since early September, command line tools that store credentials through the
Secret Service API keep losing them. In my case glab and gh. After a reboot
they report no stored token and I have to log in again.

What I think is happening

I switched from SDDM to plasma-login-manager on 2 September. Removing sddm took
/etc/pam.d/sddm with it, saved as sddm.pacsave. That old file started KWallet
and nothing else:

session  optional  pam_kwallet5.so auto_start

The replacement, /usr/lib/pam.d/plasmalogin, starts both keyring daemons, with
gnome-keyring first:

-session    optional    pam_gnome_keyring.so    auto_start
-session    optional    pam_kwallet5.so         auto_start

Since PAM runs session modules in order, gnome-keyring now claims
org.freedesktop.secrets before KWallet’s ksecretd can, and ksecretd ends up
registering only org.kde.secretservicecompat:

$ busctl --user list | grep -E "secrets|secretservice"
org.freedesktop.secrets              5793  gnome-keyring-d
org.kde.secretservicecompat          5804  ksecretd

Under SDDM, KWallet won every login because gnome-keyring was never started by
PAM at all. The result is that my credentials are now split across two stores.
Everything from before the switch is in kdewallet, and everything written
since is in gnome-keyring, including a duplicate copy of the same glab token in
both. That is why tools sometimes read a stale copy and sometimes find nothing.

What I am proposing to do

Since /etc/pam.d/ overrides /usr/lib/pam.d/, I was going to copy the vendor
file to /etc/pam.d/plasmalogin and move the two pam_kwallet5.so lines above
the pam_gnome_keyring.so lines, so KWallet gets the name back. I would rather
keep KWallet as the provider, since most of my existing secrets are already
there.

My questions

  1. Is that ordering in /usr/lib/pam.d/plasmalogin intentional, or is it just
    the upstream default that happens to differ from what the sddm package
    shipped? I would like to know whether I am working around a deliberate choice.
  2. Is an /etc/pam.d/plasmalogin override the accepted way to do this on
    Manjaro, and will it survive updates cleanly?
  3. gnome-keyring-daemon.socket is also enabled as a systemd user unit. Will
    that start gnome-keyring and claim the name regardless of the PAM ordering, or
    does fixing PAM alone settle it? This is the part I am least sure about.

Thanks very much for reading. Happy to post any further output that helps.

Post generated with AI; apologies if its tone is weird

2

I see. It is well known that mixing gnome and plasma desktop on the same system is the recipe for problems - although that may not be why you are having an issue.

The wallet/keyring is one of them. It happens because different services for identical targets are activated.

ls /etc/xdg/autostart

My initial idea of removing the gnome-keyring may not work - so I don’t know what can resolve your issue.

The gnome-keyring may be installed due to dependencies - it is not ideal - e.g. I have gnome-keyring installed because it is required by proton (vpn,mail etc.)

I have made some adjustments - clarifying my comment

3

Yeah, the Gnome keyring came in as a dependency of Proton and Bitwarden. I can live without Proton, but Bitwarden is a must have.

Any ideas on if the file change I suggested would cause any problems?

4

Seriously? Is it too much effort to ask a question on a support forum without AI?

5

I was using AI to look into the issue as it speeds things up. It suggested a change, but I wanted to ask here first. It generated a post; I reviewed it, tweaked it a little, and posted it. Its not about effort its just about what fit into my workflow.

It’s like asking why we don’t use physical dictionaries for spell check anymore.

6

No, no ideas - but generally speaking - altering the pam files should be done only after carefully examining the files - to me it sounds more like a bandaid than the solution.

I have been using plasma-login for a longer time - and I have no coexist problems - and I am using proton apps every day.

I think there is something else going on.

The library name pam_wallet5.so make me think qt5 and searching for for the file on my system reveals it is not existing.

Using a pamac search for the filename also yields empty.

pamac search pam_wallet5

The default configuration is as below and that should not be changed without fully understanding the implications - and I do not understand the PAM logic.

 $ cat plasmalogin
#%PAM-1.0

# SPDX-License-Identifier: CC0-1.0
# SPDX-FileCopyrightText: none

auth        include     system-login
-auth       optional    pam_gnome_keyring.so
-auth       optional    pam_kwallet5.so

account     include     system-login

password    include     system-login
-password   optional    pam_gnome_keyring.so    use_authtok

session     optional    pam_keyinit.so          force revoke
session     include     system-login
-session    optional    pam_gnome_keyring.so    auto_start
-session    optional    pam_kwallet5.so         auto_start

I am thinking that you should look into some system package house keeping - clearing out orphans and unused packages.

Also check if you are having any configuration in /etc/pam.d that might create the issue.

7

Its from kwallet-pam which on my machine came from the original installation:

❯ pacman -F pam_kwallet5.so
extra/kwallet-pam 6.6.6-1 (plasma) [installed: 6.7.4-1]
    usr/lib/security/pam_kwallet5.so

❯ pacman -Qi kwallet-pam
Name            : kwallet-pam
Version         : 6.7.4-1
Description     : KWallet PAM integration
Architecture    : x86_64
URL             : https://kde.org/plasma-desktop/
Licenses        : LGPL-2.0-or-later
Groups          : plasma
Provides        : None
Depends On      : glibc  kwallet  libgcrypt  pam  sh  socat
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 27.74 KiB
Packager        : Tomaz Canabrava <tcanabrava@archlinux.org>
Build Date      : 2026-08-05T07:57:37%:z
Install Date    : 2026-08-05T20:29:54%:z
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

❯ pacman -Fl kwallet-pam
kwallet-pam etc/
kwallet-pam etc/xdg/
kwallet-pam etc/xdg/autostart/
kwallet-pam etc/xdg/autostart/pam_kwallet_init.desktop
kwallet-pam usr/
kwallet-pam usr/lib/
kwallet-pam usr/lib/pam_kwallet_init
kwallet-pam usr/lib/security/
kwallet-pam usr/lib/security/pam_kwallet5.so
kwallet-pam usr/lib/systemd/
kwallet-pam usr/lib/systemd/user/
kwallet-pam usr/lib/systemd/user/plasma-kwallet-pam.service

Also this might help, although see the note about the section being disputed:

8

That is strange - I search earlier but neither pamac nor locate would find it.

I just realised I misspelled the filename :man_facepalming:

9

I did the same initially.