TW Kwallet fails to open with auto-login

English Install/Boot/Login
#1

If I disable auto-login for myself and manually type password to get to the desktop then kwallet auto-opens fine, but if I enable auto-login then kwallet fails to open.

In journtalctl there are lots of entries related to PAM or kwallet, maybe these ones are relevant:

Nov 21 13:31:18 newtw sddm[1253]: Authentication for user “stan” successful
Nov 21 13:31:18 newtw systemd[1]: Created slice User Slice of UID 1000.
Nov 21 13:31:18 newtw systemd[1]: Starting User Runtime Directory /run/user/1000…
Nov 21 13:31:18 newtw systemd-logind[1066]: New session 1 of user stan.
Nov 21 13:31:18 newtw systemd[1]: Finished User Runtime Directory /run/user/1000.
Nov 21 13:31:18 newtw systemd[1]: Starting User Manager for UID 1000…
Nov 21 13:31:18 newtw (systemd)[1283]: pam_unix(systemd-user:session): session opened for user stan(uid=1000) by stan(uid=0)
Nov 21 13:31:18 newtw (systemd)[1283]: pam_kwallet5(systemd-user:session): pam_kwallet5: pam_sm_open_session
Nov 21 13:31:18 newtw (systemd)[1283]: pam_kwallet5(systemd-user:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this.

Then, just a few lines below:

Nov 21 13:31:18 newtw sddm-helper[1280]: pam_unix(sddm-autologin:session): session opened for user stan(uid=1000) by stan(uid=0)
Nov 21 13:31:18 newtw systemd[1283]: Started Daily Cleanup of User’s Temporary Directories.
Nov 21 13:31:18 newtw sddm-helper[1280]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: pam_sm_open_session
Nov 21 13:31:18 newtw systemd[1283]: Reached target Paths.
Nov 21 13:31:18 newtw sddm-helper[1280]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: open_session called without kwallet5_key

There are more lines later, but the last one is this, again:

Nov 21 13:31:45 newtw sudo[2032]: pam_kwallet5(sudo:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this.

I use the same password for kwallet as for login and it’s called kdewallet, and it looks like the same setup as for the older TW I run on the same machine where kwallet opens without any problems. All the PAM configuration files are the same as in the older TW, too.

I tried adding “force_run” parameter to PAM config files as seen on the internet but it didn’t work. On the internet these problems went away after patches and updates, but that was years ago so it should be working fine by now.

I’ve also traced the origin of “pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this.” message to this script:

https://github.com/KDE/kwallet-pam/blob/master/pam_kwallet.c

But it might not be what causes the actual problem.

I’m using KDE with SDDM.

Any ideas?

#2

Do not use pam_kwallet with autologon. pam_kwallet needs your password to unlock wallet and your password is not available because you never enter it.

As for “not a graphical session” message - this probably warrants bug report at least to open a discussion whether pam_kwallet should be listed in these services at all.

#3

This makes sense, however kwallet opens fine on my older install on the same machine, and I haven’t seen any guide warning that kwallet won’t open if auto-login is enabled.

I just looked into my older TW journalctl and couldn’t find any difference from the new one. They are literally the same and the same “not a graphical session” message is there, too, which means it doesn’t matter, as you said. They start to differ only when the old, working install starts reporting things like this:

Nov 20 14:25:47 linux-pwfe dbus-daemon[1737]: [session uid=1000 pid=1737] Activating service nam e='org.kde.kwalletd5' requested by ':1.66' (uid=1000 pid=2052 comm="/opt/google/chrome/chrome -- no-startup-window") Nov 20 14:25:47 linux-pwfe dbus-daemon[1737]: [session uid=1000 pid=1737] Successfully activated service 'org.kde.kwalletd5'

#4

My best guess is that something triggered unlocking of kwallet.

Well, that is the same as I have on GNOME - Chrome (I have chromium, but it probably does not matter) is using keyring to store secrets and needs to unlock keyring unless it was already unlocked on login. So I get extra password prompt when start chromium the first time after reboot.

I do not normally use KDE on daily basis so am not familiar with details, but IIRC KDE changed KWallet to offer generic Secret Service API ( org.freedesktop.secrets DBus API initial support (!11) · Merge requests · Frameworks / KWallet Framework · GitLab (kde.org)) It is possible that Chrome gets confused by it.

From the logs it looks like it worked on November, 20 and stopped to work on November, 21. Were there any changes to the system? Did you update some packages - which ones? Or do you mean two different installations?

#5

No, “Nov 20” log is from when I booted into the old TW and saved journalctl output into a text file. That system’s name is “linux-pwfe”. New system’s name is “newtw”.

In the new TW I do not get this message because Chrome is not set to run at background at startup. One main reason is that kwallet is not unlocked and browsers like Chrome, Vivaldi, and Brave start complaining, prompt to open kwallet, and lose all their login cookies.

Before this message from Chrome the logs are identical - at least when I “grepped” them for pam and kwallet.

#6

Then nothing tries to unlock kwallet. What happens when you start chrome?

#7

It shows a prompt to open kwallet. I use Vivaldi as my main browser, though, so I know better what happens when I start Vivaldi - it shows a prompt but proceeds without waiting and loses access to all its stored information in the wallet, ie “login cookies” I mentioned earlier.

#8

Then it is a bug in this particular application.

1 Like
#9

Maybe so, but I expect kwallet to be open. Same happens with Chrome when the wallet is closed - it opens a window but without access to stored information.

Yesterday I tried this, btw - move the wallet to a backup and install Brave browser. On installation I was prompted to create one, so Brave needs a working wallet, too. If I close the wallet and start Brave I get prompted for password.

#10

And this is probably a bug in Chrome :slight_smile:

You may try experimenting with Chrome --password-store parameter to try different API. Also, at least Arch wiki suggests to disable KWallet auto-close to avoid such issues.

#11

I’m trying to figure out why on one install kwallet auto opens on auto login and on another doesn’t. As I said, config files are identical and journalctl messages are identical, too. On a new install all these packages came with TW, I haven’t touched anything related to PAM or kwallet.

#12

In short, if Kwallet opens without asking for a master password, that is a security issue and likely a bug in Kwallet. To open a wallet, you should always be forced to enter the passphrase manually. The other issues seem to be issues within Vivaldi and Chrome. If all is working correctly, a wallet should never open automatically.

#13

That’s not exactly what openSUSE wiki says:

To unlock the password store automatically when you log in to avoid entering a password twice, the pam module for KWallet must be installed

It does imply, though, that it won’t work with auto login where password is not entered even once.

In openSUSE documentation for Leap 15.5 there is this:

If you use the GNOME desktop environment you can configure Auto Login for a certain user and Passwordless Login for all users. Auto login causes a user to become automatically logged in to the desktop environment on boot.

There is a security warning there but it says nothing about not unlocking Gnome equivalent of kwallet. Nor does it say that auto login is possible to turn on in KDE, too, and it’s a Leap documentation so it does not exactly apply to TW.

I’m fine if the current policy is that kwallet won’t open automatically if password is not entered at login, ie with auto login, but, as far as I can tell, it’s not stated anywhere explicitly.

And it still works on my older install.

As seen on the internet, unlocked kwallet causes problems with access to wifi passwords on laptops and possibly in some other cases where KDE relies on securely stored information to work. On laptops people are likely to take security far more seriously and accept typing in their passwords at login as given reality. This machine I use is a desktop that hasn’t been touched by another human in years, however, so I don’t feel like auto login compromises anything and until now I expected it to work just the same as by typing in the password manually.

#14

Then the actual question is “why it works on your older install”. Because the behavior described in this topic is normal and expected.

You did not provide any evidence that kwallet was automatically unlocked though. The lack of prompt to unlock kwallet does not imply that kwallet is unlocked - it may also mean that applications simply won’t use kwallet.

1 Like
#15

Kwallet unlocked with auto-login on my older install for many many years, so for me this is the behavior that is normal and expected. I haven’t found any officially looking statement that kwallet won’t unlock if auto-login is enabled.

I thought these lines from journalctl were sufficient evidence:

This is what kwalletmanager shows right after boot in that older install. Kwallet IS open there.

image
image1920×1080 101 KB

I could look into more information in journalctl but what should I be looking for? I “grepped” for “pam” and “kwallet” and those log entries are identical to the new system log where kwallet doesn’t unlock. Are there any other keywords to search for? Any other logs?

#16

Right. Such information was missing :slight_smile:

What is “the other installation”? Is it Leap, Tumbleweed? If Leap, which version exactly? If Tumbleweed, which snapshot (cat /etc/os-release)?

#17 
stan@linux-pwfe:~> cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20231117"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20231117"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20231117"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
stan@linux-pwfe:~>
#18

Well, that’s pretty much current. And what if you create another user with new clean home directory and try to configure auto-login for this new user? See /etc/sysconfig/displaymanager, variable DISPLAYMANAGER_AUTOLOGIN. At least, that is where it set by YaST.

#19

Hmm … are you sure kdewallet in your another system has non-empty password? Because this is the only way to access it without explicitly unlocking I am aware of.

#20

I created a new user with its new home directory, set it to auto login, started Vivaldi and let it create “kdewallet” with blowfish encryption, gave it the same password, and it DIDN’T unlock kwallet on reboot, confirming that currently expected behavior is that kwallet auto opens only if password has been typed in at login.

Setting the password to empty, however, DID unlock it after auto-login. I then tried setting kdewallet password to empty on the new install and it unlocked there, too (well - here, I’m typing this from the new install already).

So it seems the result is that password protected kwallet won’t unlock after auto-login but if the password is set to empty then it will.

There are security implications of this for everyone to consider personally.

1 Like