KWallet5 can be auto-unlocked during login again

I've just pushed a patch to KWallet5 allowing you to have your wallet unlocked automagically during login. This patch was originally done by Alex Fiestas for KWallet4, so all credits and free beers go to him; I've merely just forward-ported it.

You'll also require kde:kwallet-pam repo and pass "-DKWALLET5=1" to cmake. This will generate pam_kwallet5.so which then can be coinstalled with the same module for KWallet4 (plus it also enables some ifdef'd code inside the module). If you're still using some KDE4/Qt4 software which is using KWallet4, you will require both modules present.

How to set up kwallet-pam can be found over at Luca's blog (though he said he'll update it for KWallet5 later, so you may want to wait a bit :).

Comments

[Nikola Kovacs]

This has been annoying me for months, so thanks!

I couldn't get this to work on Kubuntu yet (I'm missing the patch to KWallet), but I think I found some bugs:

First, it's trying to read or create ~/.local/kwalletd/kdewallet.salt, but that file is located at ~/.local/share/kwalletd/kdewallet.salt

Second, you can't have both pam_kwallet.so and pam_kwallet5.so enabled, because both use the "PAM_KWALLET_LOGIN" environment variable to detect that they've already executed, so the second one exits early with the message "pam_kwallet: we were already executed"

[Marty]

The location of kdewallet.salt is actually a composed path, which you can set using the kdehome= PAM param. It defaults to ~/.local but if you or your distro use ~/.local/share as $XDG_DATA_HOME, you should set the PAM config as such, eg.

auth optional pam_kwallet5.so kdehome=.local/share

then it will look in ~/.local/share/kwalletd.

As for the PAM_KWALLET_LOGIN, I'll have a look (I admit I haven't tested the kwallet4 much).

[Nikola Kovacs]

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html:

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

Shouldn't that be the default in pam_kwallet then?

I managed to get it to work by backporting the patch to kwallet, I'll try to get both to work now by using a different env variable for the kwallet5 version (PAM_KWALLET5_LOGIN)

[Nikola Kovacs]

I changed the env variable in both pam_kwallet5 and kwallet5 to PAM_KWALLET5_LOGIN. Both of them execute now (I see pam-kwallet: final socket path in auth.log), but only one works. If I disable pam_kwallet5.so, pam_kwallet works. If I enable both, only pam_kwallet5 works.

[Nikola Kovacs]

I also changed the socket name in /tmp to /tmp/kw_username and /tmp/kw5_username so that they don't both try to use the same one, and I had to change the startkde script so that it checks both $PAM_KWALLET_LOGIN and $PAM_KWALLET5_LOGIN and sends the environment to both. Now both kwalletd and kwalletd5 execute, but kwalletd still doesn't open the wallet if pam_kwallet5 is enabled.

[Marty]

Thanks; I've pushed the env var changes to both kwallet and kwallet-pam as well as the socket name prefix.

I'm afraid I don't know too much about kwallet internals though, so I cannot comment on why the wallet wouldn't open. I'll try to send the kwallet guys here.

[Nikola Kovacs]

Figured it out. pam_set_data and pam_get_data were using the same key, so pam_kwallet5 was overwriting pam_kwallet's hash. Now it finally works and both wallets are unlocked.

Here's the full source code: https://gist.github.com/nkovacs/8ce56653f5accc78d575

You also need to duplicate the three lines in startkde that send the environment to the socket in $PAM_KWALLET_LOGIN so that it also sends them to $PAM_KWALLET5_LOGIN:

# At this point all the environment is ready, let's send it to kwalletd if running
if test -n "$PAM_KWALLET_LOGIN" ; then
env | socat STDIN UNIX-CONNECT:$PAM_KWALLET_LOGIN
fi
if test -n "$PAM_KWALLET5_LOGIN" ; then
env | socat STDIN UNIX-CONNECT:$PAM_KWALLET5_LOGIN
fi

[Marty]

Damn good job, thanks a lot!

If you'll send me your email address to mklapetek at kde.org
I'll push the remaining changes with your name.

[Nikola Kovacs]

There's another pam_set_data / pam_get_data pair, with the key "sm_open_session", which should probably also be fixed to be unique. In my case I'm not getting the log message "open_session was called before us, calling it now", even though both pam_sm_authenticate functions execute one after the other, so the second one should be able to read "sm_open_session". I'm not sure what's happening there.
The pam_sm_open_session functions are called after both authenticates though, and everything works.

My email address is here: https://git.reviewboard.kde.org/users/nkovacs/, but I don't really mind if the commit is with your name, I'm just happy it's finally working.

[Marty]

Ok, thanks a lot, pushed all the things except the "sm_open_session",
which I don't understand enough to make a qualified decision about.

[spartan]

So, can any kind soul resume what is needed to make the chain work? This is my _not working_ setup (Chakra Linux):

plasma-workspace 5.4.0
kwallet 5.13.0
kwalletmanager 15.08.0
kwallet-pam 5.4.0

Added to /etc/pam.d/kde the following two lines:

auth optional pam_kwallet5.so kdehome=.local/share
session optional pam_kwallet5.so

Thanks