Created attachment 8210 [details]
CLI output of journalctl -b --no-pager | grep sddm

3rd last line
Jul 19 15:00:40 localhost sddm-helper[22634]: pam_kwallet5(sddm:session): 
pam_kwallet5: open_session called without kwallet5_key

I don't think this thing works at all.

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=16143

As a matter of fact, it works with Plasma 5. I have personally tested sso in Fedora 24 (version pam-kwallet-5.6.5) and KaOS Linux (kwallet-pam 5.7.2). So I guess that it is not an upstream problem. I tried a few changes and tests without success. It seems that I don't have the skills to debug the authorization process in Mageia.

Best regards,
Ulrich

Ulrich, would you mind sharing your PAM configuration when you had this working?

CC: (none) => luigiwalser

Created attachment 8292 [details]
kwallet-pam: Config from KaOS Linux

You see the config of /etc/pam.d/sddm.

I followed the sample of the Arch wiki
https://wiki.archlinux.org/index.php/KDE_Wallet

Additionally, you see the CLI output of
# journalctl -b --no-pager | grep sddm

Created attachment 8293 [details]
pam-kwallet: Config from Fedora 24

The corresponding output of Fedora 24.
Here I did not do any config changes, but only set both passwords of user login and kwallet to the same value.

Best regards,
Ulrich

Thanks Ulrich.  So it's the same PAM configuration w.r.t. kwallet-pam/pam-kwallet in Mageia as the other two distros.  I wonder why it doesn't work for you only in Mageia.  As for my issue with /etc/skel not getting copied, I haven't tried another distro to see if they have the same issue.

I figured out a possible reason. According to
https://wiki.mageia.org/en/Auto_inst#authentication_.28required.29
Mageia 6 switched from blowfish to sha512 as autentication method.

The Arch wiki states that blowfish is the only method supported
https://wiki.archlinux.org/index.php/KDE_Wallet

Can I switch to blowfish to test this issue?

Ulrich

What I tested so far:

1) replaced in /etc/libuser.conf 
-------------------------------
## crypt_style = sha512
crypt_style = blowfish
modules = files shadow
-------------------------------

2) replaced in /etc/pam.d/system-auth
----------------------------------------------------------------------------------
#password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_unix.so try_first_pass use_authtok nullok blowfish shadow
----------------------------------------------------------------------------------

3) set root password, and identical user + kwallet password
The password hash in /etc/shadow starts now with $6$... just like Fedora.

4) reboot
Authentication went fine, but still on SSO.

Still no clue what is the difference.

s/still on SSO/still no SSO/

I tested now Mageia-6-sta2-LiveDVD-Plasma-x86_64-DVD. kwallet-pam-5.8.5-1.mga6 is now included, automatically installed.

I created a wallet named kdewallet with KwalletManager and set it as default wallet. It still does not open at login. I could not spot any error message.

---------------------------------------------------------------------------------
# journalctl -ab | grep kwallet
Jan 09 17:42:54 localhost ksmserver[3379]: ksmserver: Starting autostart service  "/etc/xdg/autostart/pam_kwallet_init.desktop"
Jan 09 17:42:54 localhost ksmserver[3379]: ksmserver: autostart service "/usr/libexec/pam_kwallet_init" finished with exit code  0
---------------------------------------------------------------------------------

Ulrich

I am getting a very similar problem on Cauldron. kwallet-pam installed. Entries in pam.d/{sddm,login,kdm} and I get the 
"No password" pam error in the logs. 
Jan 16 17:58:26 planet systemd-logind[861]: New session c3 of user unruh.
Jan 16 17:58:26 planet sddm-helper: pam_unix(sddm:session): session opened for user unruh by (uid=0)
Jan 16 17:58:26 planet sddm-helper: pam_kwallet5(sddm:session): (null): pam_sm_open_session
Jan 16 17:58:26 planet sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: open_session called without kwallet5_key
Jan 16 17:58:26 planet sddm-helper: pam_unix(sddm-greeter:session): session closed for user sddm

are in /var/log/auth.log (I am using rsyslog)

Something is not getting set up properly and the password is not being transfered to opening kwaller.

CC: (none) => unruh

Note here are my entries in pam.d

sudo grep kwallet *
kdm:auth      optional    pam_kwallet.so
kdm:session   optional    pam_kwallet.so
login:-session   optional     pam_kwallet5.so auto_start
sddm:auth       optional    pam_kwallet5.so
sddm:session    optional    pam_kwallet5.so auto_start

Putting a trace into /usr/libexec/pam_kwallet_init neither of PAM_KWALLET_LOGIN or PAM_KWALLET5_LOGIN exist in the environment, so that script does nothing.  I have no idea what was supposed to set those in the environment, or what they were supposed to be set to (socket?), but they are not being set. 
It seems it should be set in pam_kwallet5.so, but either the script is run before that is set or pam_kwallet5.so is failing to set it (but there are no log entries saying it is not being set).
Is /etc/xdg/autostart/pam_kwallet_init.desktop being run too soon-- part of the parallelization of systemd? Although there is no evidence of PAM_KWALLET_LOGIN after X comes up.

My assumption and test in https://bugs.mageia.org/show_bug.cgi?id=18986#c9 is invalid. $6$... in /etc/shadow is indeed sha512.

As pam-kwallet is broken and no correction in sight, it should be removed from the packagelists and moved to testing.

Ulrich

Also trying to solve this problem, because network manager asks me for the kwallet password every time I login, so it can connect to the wifi

CC: (none) => nelg

Created attachment 9262 [details]
CLI output: journalctl -b --no-pager | grep sddm

retested with Mageia-6-rc-x86_64-DVD.iso of April 27th.

I see now a status change: kwallet-pam is now installed by default, though there is no dependency which requires it. It still does not work.

Raised importance to high:critical, as now an installed package is broken.

Severity: normal => critical
Priority: Normal => High

While this is a critical bug should this be an M6 release blocker?
Thanks

CC: (none) => wilcal.int

This is not a release blocker, it can be fixed by an update after the release. It's also not of "critical" severity, which should be used if there was risks for the installed system, or crashes of the program. Here it's "just" one feature not working as expected (though I would really like it fixed myself, it's annoying to have to type my password twice before I can get WiFi to connect).

Severity: critical => major

Thanks Rémi

I suggest, that when we get this fixed, we also make sure that we make a minor patch to the kwallet new wallet dialog box, so that it recommends people use the same password for the default kdewallet as their login password, and that they keep the two in sync.

It would be ideal if this just happened without having to do anything.

I suspect otherwise, many users will set a different password for the kdewallet wallet, because they don't know that pam_kwallet5 will open it for them and make life easy if it's the same.  Maybe also set the default to classic rather than GPG based wallets.

As I mentioned, it seems that kwallet-pam cannot get the password from pam to pass on to kwalletd. The password keeps being reported as empty, and trying to put in a debugging print statement after kwallet-pam claims to have gotten the password yields nothing. Ie, there seems to be something wrong either with pam which is not giving the password when asked for it, or the timing (it may be being asked before it actually gets the password from the login process). Unfortunately I have no idea how pam works, so I cannot debug it. It may be that pam has changed so that it hangs onto the password for the shortest possible time-- just enough to validate the user, but then it gets erased before kwallet-pam asks for it.

I've had a crack at seeing if we can get the password in sddm.

I wrote the following little script:   /usr/local/bin/logintest.sh
#!/bin/bash
logger "BUG:18986 Login testing"
read -r pw
logger "BUG:18986 debug pw: $pw"

Then, when added to /etc/pam.d/sddm  like so:

#%PAM-1.0
auth       required    pam_env.so
auth       sufficient  pam_succeed_if.so user ingroup nopasswdlogin
auth       optional    pam_exec.so expose_authtok seteuid /usr/local/bin/logintest.sh
auth       optional    pam_kwallet5.so
auth       include     system-auth
account    include     system-auth
password   include     system-auth
session    optional    pam_keyinit.so force revoke
session    required    pam_namespace.so
session    optional    pam_kwallet5.so auto_start
session    include     system-auth
session    required    pam_loginuid.so
session    optional    pam_console.so

It successfully logs the password.

So, I added in kwallet5.so, and get

May 05 11:57:40 x1.linuxsolutions.co.nz sddm-helper[19042]: pam_kwallet5(sddm:auth): (null): pam_sm_authenticate
May 05 11:57:40 x1.linuxsolutions.co.nz sddm-helper[19042]: [PAM] returning.
May 05 11:57:40 x1.linuxsolutions.co.nz sddm[1498]: Authenticated successfully
May 05 11:57:40 x1.linuxsolutions.co.nz sddm-greeter[19024]: Message received from daemon: LoginSucceeded
May 05 11:57:40 x1.linuxsolutions.co.nz sddm-helper[19042]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
May 05 11:57:40 x1.linuxsolutions.co.nz sddm-helper[19042]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
May 05 11:57:40 x1.linuxsolutions.co.nz sddm-helper[19042]: pam_kwallet5(sddm:session): pam_kwallet5: final socket path: /tmp/kwallet5_nelg.socket


How did you put your debug statement in kwallet to know it's getting an empty password?

I suspect it could be if kwalletd5.so is added after the system-auth line in sddm, it won't work, because system-auth has sufficient in it's auth, so will stop processing.

kdm called the system-auth module with substack, which would return after system-auth, where sddm is calling it with include, which does not.

When I try with /etc/pam.d/sddm lines:

auth       substack     system-auth
auth       optional    pam_kwallet5.so
session    optional    pam_kwallet5.so auto_start

I get two /usr/bin/kwalletd5 processes, one with --pam-login 15 18
and the other without.  and still prompted for a password.

Maybe this bug report had some information useful:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798786

I put some debugging commands into the source code for kwallet to see what was being returned. Usually nothing was returned and I got an error in the journalctl log file saying that kwallet5 got no password. 
I will try your "substack" and see if I get better results.

By the way in my pam.d/kdm file on mga5 the kwallet lines have a - in front of them.
-auth  optional pam_kwallet.so
Any idea what that - sign does?
I know pam not at all, and reading the man pages and the web really leave me not very much better educated, and I have found nothing that says what that - sign means.

Anyway I will try the substack suggestion, and see if it helps.

PS. I am not sure at all why one would also want kwallet5.so under session as well as auth. Especially as kwallet5.so then gets run when the session closes down, as well as when it opens.
I am not sure that it might not be a good idea for pam_kwallet5 to close down that socket when kwalletd gets the password, since as it is it leaves a socket open at all times for any other program to extract your login password from. Sounds dangerous.

With respect to the release blocker status, perhaps it need not be, as it technically could be fixed post-release, but:

1) Given how long problems with this package have persisted, I don't expect it will be, and

2) if this package is broken, it shouldn't be installed and included in the PAM configuration by default, and if it still is, *that* should be fixed before we release.

It is far too useful a package to be given up on. I agree that it should not be a release blocker since it could be fixed afterwards, and I suspect that we are getting close to a solution (see comment 25).
The problem it seems is actually getting someone to look seriously at it. I reported it upstream to the kde bugs, but it has attracted no attention there, so solutions will probably have to come from downstream. The Debian bug report seems to be attracting attention.

I'm not saying to drop the package, just to not include it in our PAM configuration by default.  My main concern about it is how it breaks correct automatic creation of home directories (possibly breaking pam_mkhomedir), as I mentioned in Comment 7 and elsewhere.

(In reply to w unruh from comment #26)

> By the way in my pam.d/kdm file on mga5 the kwallet lines have a - in front
> of them.
> -auth  optional pam_kwallet.so
> Any idea what that - sign does?
> I know pam not at all, and reading the man pages and the web really leave me
> not very much better educated, and I have found nothing that says what that
> - sign means.
> 
> Anyway I will try the substack suggestion, and see if it helps.

The minus sign originates from the Arch Wiki. It should ensure that login continues on error, otherwise login would fail. This hint is now removed, the keyword option being sufficient.

(In reply to w unruh from comment #27)
> PS. I am not sure at all why one would also want kwallet5.so under session
> as well as auth. Especially as kwallet5.so then gets run when the session
> closes down, as well as when it opens.
> I am not sure that it might not be a good idea for pam_kwallet5 to close
> down that socket when kwalletd gets the password, since as it is it leaves a
> socket open at all times for any other program to extract your login
> password from. Sounds dangerous.

I tested several other distributions: openSUSE Leap, Fedora 25, KaOS.
It is everywhere under auth and session. And working.
Does it really pass a plain password or a hash instead?

(In reply to w unruh from comment #26)
> I put some debugging commands into the source code for kwallet to see what
> was being returned. Usually nothing was returned and I got an error in the
> journalctl log file saying that kwallet5 got no password. 

Did this debugging end up in /bin/kwalletmanager5 or /usr/bin/kwalletd5 ?


> I will try your "substack" and see if I get better results.
> 
> By the way in my pam.d/kdm file on mga5 the kwallet lines have a - in front
> of them.
> -auth  optional pam_kwallet.so
> Any idea what that - sign does?
> I know pam not at all, and reading the man pages and the web really leave me
> not very much better educated, and I have found nothing that says what that
> - sign means.
> 

I also didn't know what the - sign was, but a friend pointed me to it in the manual:  man 5 pam.d

This section: 
"If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session."


So, I removed the - sign while debugging.

(Ogilvie 25)
That debian patch is already in Mageia in /usr/libexec/pam_kwallet_init which gets run from /etc/xdg/autostart/pam_kwallet_init.desktop.

Minor(?) Bug in pam_kwallet.c:

There is a bug in pam_kwallet.c. The variable "needed" in the routine "start_kwallet"  is too small by 1. The author used snprintf to measure the size of the string needed for the variable "fullSocket", but forgot that snprintf returns the number of bytes written excluding the terminal \0, but requires the number of bytes Including the trailing \0.
This meant that the socket was created with the name having the terminal .socke  rather than .socket

This however seems to be a cosmetic rather than functional bug, as adding 1 to "needed" gives the terminating .socket, but does not fix the problem.

I give up trying to trace this stuff. i do not know why it is tyring to get the environment via a socket since kwalletd5 was started with execve with the environment set by the execve. But if I comment out the waitForEnv() call, I get an error of No protocol specified, and it still does not work. i have o idea what is issuing that error message since that message is nowhere in the source code of kwalletd.

Also all of the error and debug messages in kwalletd5 are either qDebug or qWarning streams, which are useless to me.

When testing this, do you also have kwallet-daemon (the older non-5 version installed?)

Looking at the fedora configuration, they have both setup.  This is maybe a better user experience, because old kdewallets then get prompted to be imported.

Also, we get an error in the journal without it, of it trying to find it for doing a migration.

No, I do not have the old one (kwallet rather than kwallet5) running, but I did not run the old version ever on this computer, so there is nothing to import or migrate.

The error in 35 seems to come from d-bus. (I get that error if I do 
sudo kwalletmanager
and it says the error  is from d-bus.)

(In reply to Glen Ogilvie from comment #36)
> When testing this, do you also have kwallet-daemon (the older non-5 version
> installed?)
> 
> Looking at the fedora configuration, they have both setup.  This is maybe a
> better user experience, because old kdewallets then get prompted to be
> imported.
> 
> Also, we get an error in the journal without it, of it trying to find it for
> doing a migration.

I always tested fresh installs with kwallet5, too. I'm afraid, never saw I working migration in any distribution. But that is another issue. Users got utterly confused with 2 working instances of kwallet, trying to get rid of both.

I agree, having both is confusing, but don't like the error in the logs when it tried to start the second instance.

I see some interesting stuff with d-feet (dbus explorer), including that a second kwalletd5 process starts, whenever an app tries to use kwallet via dbus.

IE: 
nelg     28053     1  0 23:24 ?        00:00:00 /usr/bin/kwalletd5 --pam-login 15 18
nelg     28055     1  0 23:24 ?        00:00:00 /usr/bin/kwalletd --pam-login 15 19 --nofork
nelg     30199     1  0 23:40 ?        00:00:00 /usr/bin/kwalletd5


If I kill off the kwallet processes 30199 (this one is not the one started at login via pam), and then use d-feet to open the kwallet5 process in dbus, a new kwalletd5 opens.  I suspect this one, does not know to use the environment variable, as it does not start with the flags for pam.

This I think is what network manager is doing when it tries to open kwallet, it calls dbus, which instead of using the running process, starts a new one.

In the journal on a working kwalletd5, such as on fedora, does anyone see
"kwalletd5: Waiting for hash on" message, as per line: 83 of this code
https://github.com/KDE/kwallet/blob/master/src/runtime/kwalletd/main.cpp

or is everyone getting:
 org.kde.kwalletd[15959]: Lacking a socket, pipe: 0, env:0

In the journal / log.

The function at line 114: checkPamModule  seems to be showing that it' not picking up the necessary stuff,  I suspect due to it the starting of another kwalletd5 process which does not have the args it needs, so would not work.

As I mentioned in 34, kdewallet5 hangs on waitForEnv() in checkPamModule, but I have no idea why it is getting the environment from kwallet-pam, since it was started with the environment. Also I see nowhere that the name of the socket is ever used (/run/user/<UID>/kwallet.socke). I would have thought a new version of kwalletd would try to attach to that. Or perhaps attach to d-bus to ask for the password hash-- 

See the attachment for the kwallet lines from a current login. The stuff from 07:16 15 is from the pam login. Note that it ends with those dbus messages.
The suff from 17:22 and follows is from my starting Chrome which asks for kwallet password. (Note that I use Network Center for wireless, not NetworkManager)


What really confuses me are the claims that other distros this whole thing actually does work. But from the current state it would seem that there is a dbus problem.
The pam-kwallet5 does not manage to attach itself to Dbus, and the subsequent ones cannot use dbus to get the hash?

Created attachment 9276 [details]
journalctl -b|grep kwallet  after startup and starting Chrome

The kwallet5 output is due to my replacing the log prinf statements in kwalletd/main.cpp with syslog(LOG_ERR,  statements. Why anyone would write a program which runs at boot with printf  for errors/info I do not know.
(Note that the Hash in the log is not the complete Hash).

Looking at kwalletd5 it gets weirder and weirder. 
In main.cpp, routine main, the system first checks if PAM_KWALLET5_LOGIN
exists in the environment, and if it is runs checkPamModule to get the hash, 
but then it sets up a QApplication function. But when kwalletd5 is run by kwallet-pam, X is not yet set up at all, so this fails. But that is ass backwards. Once it has the hash, it should open up the wallet, not start setting up Qt windows etc. When something else (Chrome eg, or networkManager ) wants to open the wallet, then setting up windows etc is appropriate, but no under pam.


I really do not understand this but this program really does not seem to make any sense to me. Maybe someone else can make sense of it?

Are we sure that the distros which do successfully use kwallet are not using the old version, rather than this new version? (I am looking at kwallet-5.32. The mga5 version (5.5) does not have all of this junk. But then there main.cpp is a totally different program and does not seem to interface with kwallet-pam.

I have Fedora 24 installed, so will do some tests on it and let you know the results if that is useful:

It comes with these versions:
kwalletmanager-15.04.3-4.fc24.x86_64
kf5-kwallet-libs-5.27.0-1.fc24.x86_64
kf5-kwallet-5.27.0-1.fc24.x86_64
pam-kwallet-5.7.5-1.fc24.x86_64
kwalletmanager5-16.08.2-1.fc24.x86_64

I'll do this sometime in the next day and a half.


Any idea on why we get more than one execution of /usr/bin/kwalletd5  ?  or does that not happen to everyone?

Created attachment 9282 [details]
CLI output: Fedora 25

I have here Fedora 25. It was originally installed as Fedora 22 and upgraded since then.

Version list:
# rpm -qa | grep kwallet
kwalletmanager5-16.12.3-1.fc25.x86_64
signon-kwallet-extension-16.12.3-1.fc25.x86_64
kf5-kwallet-libs-5.33.0-1.fc25.x86_64
kf5-kwallet-5.33.0-1.fc25.x86_64
pam-kwallet-5.9.4-1.fc25.x86_64
kwalletmanager-15.04.3-5.fc25.x86_64

I don't recall, if I have modified /etc/sddm manually.

I finally got kwallet5-pam to work. I will try to impliment the fixes and attach a patch to kwallet-pam and kwallet itself, but let me describe what I found since I suspect that there are far better fixes possible. 

Changes in kwallet-5.32.0/src/runtime/kwalletd/main.cpp

a) In the subroutine checkPamModule 
Remove the waitForEnvironment() test in 
if(hash == nullptr||waitForEnvironment()==-1){
and replace with 
if(hash == nullptr){
The waitForEnvironment() function for some reason never returns, and kwalletd5 
is started in kwallet5-pam with the environment anyway in the execve function.

b) In main(), put
if (hash != nullptr) sleep(2);
into the program just after 
hash=checkPamModule(argc,argv) at the beginning of the routine.

There is a race condition which kwallet5 always looses in which kwalletd5 runs before X is up. This causes a problem in that when Qt tries to set up, there is no
X and no :0 DISPLAY to connect to, and the Qt routines fail. 

I do this only if hash is not null,  since as I know it is only after kwallet-pam that the hash is set by this.
And 2 sec is not a long wait. 

c)In kwallet-pam-5.9.2/pam_kwallet.c
put

set_env(pamh,"USER","userInfo->pw_name");
set_env(pamh,"HOME",userInfo->pw_dir);
somewhere after userInfo is defined. 



Doing this, the wallet is open when I log on.

The biggest kludge is that 2 sec wait in kwalletd5. There should be some way of asking if X is up before trying to run Qt routines. The 2 sec was not chosen after any long testing. It was the first thing I tried and it worked, and I have wasted enough time on this.

That seems to me like it is better to ship with Mageia 6, even with the kludge.   I'd be happy to try it if you have a compiled version with your patch handy.

I think maybe we can come up with something that does not have sleep 2 eventually, ie, check for a at least 10 processes running in the X session or find out an actual way to check for X running.  maybe a call to XOpenDisplay?
http://stackoverflow.com/questions/637005/how-to-check-if-x-server-is-running

While we are discussing how it works, I've been trying to figure out why
/usr/libexec/pam_kwallet_init: does

env | socat STDIN UNIX-CONNECT:$PAM_KWALLET5_LOGIN

ie, how this actually does anything.  I'm not sure where STDIN ends up going to when xdg run's an autostart script.  Anyone know why / if the above works?

Nice work guys on debugging this issue and finding a potential fix. We would probably consider adding a patch, even imperfect, if it improves the situation for everyone, but don't hesitate to get in touch with upstream developers to go deeper in the understanding of this issue.

Re 48-- I am also not sure that it does anything. It is an implimentation of the Debian "fix" that you pointed out, and as far as I could see, really has no purpose, especially as often pam_kwallet_init runs well after the pam-kwallet has run, and kwalletd5 has run. 
Note that that STDIN I presume is the output of the env program, which in this case is the env. I think this may have been a vain attempt to get that waitForEnvironment() call in kwaletd5 to work. Ie, this is supposed to feed the environment into the socket (what a kludge)

Hmm. I wonder if I put in that sleep(2) before checkPamModule runs, whether this will dump the environment of the user into kwalletd5 via the waitForEnvironment() function. Ie, whether the same race that destroys Qt also destroys this socket.

So, it would seem that there is something weird about Mageia 6 in the timing between the runnning of pam-kwallet and the bringing up of X.

Putting in sleep(2) without the other changes did not work.

A compiled version of the new kwallet rpms together with the source rpms (patched) is in
ftp.theory.physics.ubc.ca/outgoing/kwallet

(In reply to w unruh from comment #51)
> Putting in sleep(2) without the other changes did not work.
> 
> A compiled version of the new kwallet rpms together with the source rpms
> (patched) is in
> ftp.theory.physics.ubc.ca/outgoing/kwallet

Thank you.. Permissions on those files need to be readable by the ftp server process, can't download.  maybe chmod 644 on the files.

Oops. Fixed.

Note that this also seems to have fixed Chrome's not reporting that it was killed improperly and asking if I want to restore the previous sessions. Before the fix that never happened anymore. After the fix it is again happening. I think that the request to enter the password for kwallet was short circuiting the "restore session" software. 
Ie, this patch seems to be working well. 
Have others tried it?

I also just noticed that I put the updated rpms in there without changing the version numbers. (Well kwallet-pam-5.9.2-1-mga6 does not exist in the repretory-- I used the kwallet.spec file from 5.8.6 and put in the new tar and version number from the recently releases kwallet-pam from kde. But the kwallet-5.32.0 has the same label as the Mageia 6 version but is the already patched version. Sorry about that.

I do not know if the patch would also work on kwallet-pam-5.8.6 (the version on Mageia 6) I downloaded 5.9.2 in the hope that the bug would have been fixed there when I started to work on this problem, and never went back.

One of the things working on this bug makes clear is that kwallet-pam works ONLY if one logs on in runlevel 5. If one tries to log in in runlevel 3 and runs startx, kwallet will not be opened and cannot be opened with kwallet-pam. I have no idea why kwalletd5 should only work in X. While it is true that it opens a window for the password
that could equally be done from the command line as well. Someone was not thinking very far. 
And kwalletd5 does not really need X to open the wallet from kwallet-pam-- it never uses any X, but it sets everything up with Qt as if it did need X.

Please, could you try kwallet-pam-5.8.6-2.mga6, it should fix this bug with a pam stack properly configured.
While most of distro still use socat 1.7.x (stable), Mageia uses socat 2.0 beta.
With socat 2.0, socat properly transfers env to kwallet-pam only if we explicitly use unidirectional mode.

CC: (none) => lmenut

I have been running unrah's patched version for the last couple of days.. So far, I'd say it's working quite well in my tests.  Network manager connects and uses it perfectly.

Very interesting that socat could be impacting this problem.  I guess that's something to test as well.

I'll revert to the other version, and test with 
 env | socat -u STDIN UNIX-CONNECT:$PAM_KWALLET5_LOGIN

Socat does not affect my version because I eliminated the downloading of the environment via waitForEnvironment in kwalletd5 which depends on socat feeding the socket. socat is probably what caused the hang of the waitForEnvironment call in the original version. 
However, kwallet-pam is idiotic. It passes the environment variable 
KWALLET5_PAM_LOGIN in the enviroment via execve, but did not pass the HOME in the environment which is crucial to the operation of the kwalletd5 due to Qt.
Instead there was the complete kludge of setting up a socket, attaching socat to the socket and then sending the environment (of which the only thing needed was HOME) to kwallet5d in that way. This is just silly. Since you HAVE to pass KWALLET5_PAM_LOGIN via execve anyway, why not also pass HOME?

Note that if kwalletd5 is run by some user program, then it already has the user's environment already and waitForEnvironment is not needed either. It is a source of bugs (as we have seen) without any purpose. 

Note that the enviroment was not the only problem because kwalletd5 was running before X was properly up, and Qt would hang anyway because it did not have X to set up the windows it never used when called from pam.

Ie, I believe that you will find that it will still not work because of the X race condition, unless the waitForEnvironment call takes long enough to allow X to come up. Ie, even if it works, the program is fragile and may well only work sporadically. (a 2 sec pause may be enough but that fragility is why I would really like it if kwalletd5 actually checked if X was up before setting up Qt.
Even better would be if kwalletd5 got rid of all its X stuff so that it could also work even if X was not running at all.

(In reply to w unruh from comment #57)
> Socat does not affect my version because I eliminated the downloading of the
> environment via waitForEnvironment in kwalletd5 which depends on socat
> feeding the socket. socat is probably what caused the hang of the
> waitForEnvironment call in the original version. 
> However, kwallet-pam is idiotic. It passes the environment variable 
> KWALLET5_PAM_LOGIN in the enviroment via execve, but did not pass the HOME
> in the environment which is crucial to the operation of the kwalletd5 due to
> Qt.
> Instead there was the complete kludge of setting up a socket, attaching
> socat to the socket and then sending the environment (of which the only
> thing needed was HOME) to kwallet5d in that way. This is just silly. Since
> you HAVE to pass KWALLET5_PAM_LOGIN via execve anyway, why not also pass
> HOME?
> 
> Note that if kwalletd5 is run by some user program, then it already has the
> user's environment already and waitForEnvironment is not needed either. It
> is a source of bugs (as we have seen) without any purpose. 
> 
> Note that the enviroment was not the only problem because kwalletd5 was
> running before X was properly up, and Qt would hang anyway because it did
> not have X to set up the windows it never used when called from pam.
> 
> Ie, I believe that you will find that it will still not work because of the
> X race condition, unless the waitForEnvironment call takes long enough to
> allow X to come up. Ie, even if it works, the program is fragile and may
> well only work sporadically. (a 2 sec pause may be enough but that fragility
> is why I would really like it if kwalletd5 actually checked if X was up
> before setting up Qt.
> Even better would be if kwalletd5 got rid of all its X stuff so that it
> could also work even if X was not running at all.

I agree with you. 

My interpretation of what it was doing, was the purpose of the waitForEnvironment call was that socat would be called by the startkde script, which would deal with the timing / wait for 2 seconds problem, because the position in start kde that the socat call was made, was after X was up and running.   I might not have this right, as it's just based on my understanding of the problem.

(In reply to Luc Menut from comment #55)
> Please, could you try kwallet-pam-5.8.6-2.mga6, it should fix this bug with
> a pam stack properly configured.
> While most of distro still use socat 1.7.x (stable), Mageia uses socat 2.0
> beta.
> With socat 2.0, socat properly transfers env to kwallet-pam only if we
> explicitly use unidirectional mode.

It still doesn't work with the same error message
sddm-helper[7044]: pam_kwallet5(sddm:session): pam_kwallet5: open_session called without kwallet5_key

If the problem depends on timing or a race condition, I would have guessed the reason is a poor configuration of systemd.

OK, I was wrong. Running the updated kwallet-pam 5.8.6-2.mga6 with the unpatched  kwallet-5.32.0 also works. Ie, this does not need the 2 sec sleep. I guess somehow the libexec/pam_kwallet_init  delays the startup of kwallet5 long enough that X is properly up when the Qt programs start to run. Or there is something in the environment which allows Qt to start up properly. 

The error in 59 I think comes about because of some problem in pam.d/sddm

Here is my version.

auth       required    pam_env.so
auth       sufficient  pam_succeed_if.so user ingroup nopasswdlogin
auth       substack     system-auth
auth       optional    pam_kwallet5.so
account    include     system-auth
password   include     system-auth
session    optional    pam_keyinit.so force revoke
session    required    pam_namespace.so
session    include     system-auth
session    required    pam_loginuid.so
session    optional    pam_kwallet5.so
session    optional    pam_console.so

Note the use of substack in the first system-auth call rather than include.
and pam_kwallet occurs after the system-auth call in both cases.

I confirm, SSO works now with /etc/pam.d/sddm as of Comment #60. Thanks for your outstanding work!

For the records, I used the version in Comment #1 to test. One cannot describe a config as bugged, which works in any other distribution.

I would like to close the report as fixed, but the pam config should be updated via packaging. One should also consider Gnome keyring, since Gnome can be invoked by sddm. It should be mentioned in the Release notes, since kwallet-pam is widely unkńown and quite useful.

Again, many thanks for all contributors!

Ulrich

Status changed as works for me according comments #60 and #61.
Status fixed would need a test of a fresh install.

Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED

*** Bug 16143 has been marked as a duplicate of this bug. ***