Anyone successfully using pam_kwallet?

English Applications
1

Hi there,

I use pam_kwallet to have my KDE kwallet automatically opened when signing into KDE.
Sometimes it works, sometimes it doesn´t.
Sometimes the wallet is open after logging in, but very often the wallet is still closed and I need to open it manually.

I´m not able to find a reason why it failes sometimes, there is no error.

I observed only one thing, on my older machine with an AMD FX CPU it has always worked, always.
The occasional failing started to occur on my AMD Ryzen system. A sign for a timing issue?

2

I used it with Leap 15.0. However, at the time of the Leap 15.1 release, it had problems (it broke “sudo”). So I went back to using a GPG key for encrypting the wallet. That problem has since been fixed, as far as I know.

In my experience with Leap 15.0 and with Leap 15.1 during Beta testing, it worked fine as long as I was using either “sddm” or “gdm” for graphic logins. It never worked with “lightdm”.

I have never seen the intermittent behavior that you seem to be describing.

3

I’m using it without any issues on Leap 15.1 – KDE Plasma – SDDM.

  • Classic, Blowfish encryption.
  • ‘/etc/pam.d/sddm’ contains “auth optional pam_kwallet5.so
    ” and “session optional pam_kwallet5.so auto_start”.

For further information, check the Arch Linux page: <https://wiki.archlinux.org/index.php/KDE_Wallet>.

4

When you say, it broke sudo, may this be related to dozens of messages like?


Dez 15 22:22:37 foo1 sudo[22695]: pam_kwallet5(sudo:session): (null): pam_sm_close_session
Dez 15 22:22:37 foo1 sudo[22695]: pam_kwallet5(sudo:setcred): (null): pam_sm_setcred
Dez 15 22:22:52 foo1 sudo[22718]: pam_kwallet5(sudo:setcred): (null): pam_sm_setcred

I get plenty of those messages in the logs…

5

I don’t really know. I rarely use “sudo”.

There was a bug report about it: Bug 1133808

See also Bug 1134929

6

Yes, yes, during the Leap 15.1 Beta testing, there was an issue between KWallet and, everything else that used ‘sudo’ – ‘sudo’ was broken because, something got forgotten in libgcrypt20 but, that got fixed for the Leap 15.1 release …

Yes, the systemd Journal collects quite a few message such as:


Sep 02 09:30:03 xxx sddm-helper[5220]: pam_kwallet5(sddm:session): pam_kwallet5: final socket path: /run/user/59900/kwallet5.socket
Sep 02 09:30:07 xxx ksmserver[5341]: ksmserver: Starting autostart service  "/etc/xdg/autostart/pam_kwallet_init.desktop" ("/usr/lib64/libexec/kf5/pam_kwallet_init")
Sep 02 09:31:11 xxx sddm-helper[6438]: pam_kwallet5(sddm:session): pam_kwallet5: final socket path: /run/user/59901/kwallet5.socket
Sep 02 09:31:13 xxx ksmserver[6598]: ksmserver: Starting autostart service  "/etc/xdg/autostart/pam_kwallet_init.desktop" ("/usr/lib64/libexec/kf5/pam_kwallet_init")
Sep 02 09:32:01 xxx kcheckpass[6215]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:32:01 xxx kcheckpass[6215]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:32:01 xxx kcheckpass[6215]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred
Sep 02 09:32:27 xxx kcheckpass[6956]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:32:27 xxx kcheckpass[6956]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:32:27 xxx kcheckpass[6956]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred
Sep 02 09:33:03 xxx kcheckpass[7059]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:33:03 xxx kcheckpass[7059]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:33:03 xxx kcheckpass[7059]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred
Sep 02 09:33:42 xxx su[7214]: pam_kwallet5(su-l:auth): (null): pam_sm_authenticate
Sep 02 09:33:42 xxx su[7214]: pam_kwallet5(su-l:auth): (null): we were already executed
Sep 02 09:34:02 xxx su[7234]: pam_kwallet5(su-l:auth): (null): pam_sm_authenticate
Sep 02 09:34:02 xxx su[7234]: pam_kwallet5(su-l:auth): (null): we were already executed
Sep 02 09:34:02 xxx su[7234]: pam_kwallet5(su-l:setcred): (null): pam_sm_setcred
Sep 02 09:34:02 xxx su[7234]: pam_kwallet5(su-l:session): (null): pam_sm_open_session
Sep 02 09:34:02 xxx su[7234]: pam_kwallet5(su-l:session): (null): we were already executed
Sep 02 09:36:19 xxx su[7368]: pam_kwallet5(su:auth): (null): pam_sm_authenticate
Sep 02 09:36:19 xxx su[7368]: pam_kwallet5(su:auth): (null): we were already executed
Sep 02 09:36:19 xxx su[7368]: pam_kwallet5(su:setcred): (null): pam_sm_setcred
Sep 02 09:36:19 xxx su[7368]: pam_kwallet5(su:session): (null): pam_sm_open_session
Sep 02 09:36:19 xxx su[7368]: pam_kwallet5(su:session): (null): we were already executed
Sep 02 09:39:15 xxx polkit-agent-helper-1[7645]: pam_kwallet5(polkit-1:auth): (null): pam_sm_authenticate
Sep 02 09:39:29 xxx su[7234]: pam_kwallet5(su-l:session): (null): pam_sm_close_session
Sep 02 09:39:29 xxx su[7234]: pam_kwallet5(su-l:setcred): (null): pam_sm_setcred
Sep 02 09:39:30 xxx su[7368]: pam_kwallet5(su:session): (null): pam_sm_close_session
Sep 02 09:39:30 xxx su[7368]: pam_kwallet5(su:setcred): (null): pam_sm_setcred
Sep 02 09:40:05 xxx kcheckpass[7112]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:40:05 xxx kcheckpass[7112]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:40:05 xxx kcheckpass[7112]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred
Sep 02 09:40:25 xxx kcheckpass[7684]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:40:25 xxx kcheckpass[7684]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:40:25 xxx kcheckpass[7684]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred
Sep 02 09:41:33 xxx kcheckpass[7742]: pam_kwallet5(kscreenlocker:auth): (null): pam_sm_authenticate
Sep 02 09:41:33 xxx kcheckpass[7742]: pam_kwallet5(kscreenlocker:auth): (null): we were already executed
Sep 02 09:41:33 xxx kcheckpass[7742]: pam_kwallet5(kscreenlocker:setcred): (null): pam_sm_setcred

But, none of these informational messages mean that, KWallet is broken – they’re only a trace of what’s going on to help the developers analyse any issues which may or, may not occur …

7

Ah,ok. But wouldn´t it be sensible to disable these messages in production release? According to Google, quite a number of people are bothered by this “noise”. E.g. I run a script from within conky that runs commands with sudo. This script gets executed every few seconds, thus I have many, many of these messages…
Oh, sudo has rules to make executing commands quiet, if I know the parent process that starts kwalletd / kwalletmanager, could this be a way to avoid these messages?

8

AFAICS, the only way to influence some reduction of the “trace noise” is, to raise a Bug Report against the application which writing these systemd Journal entries.

Use “visudo” to edit ‘/etc/sudoers’ – by default “Defaults log_output” is commented out but, we may have to enable “Defaults !log_output” to keep “sudo” quiet …