@fvogt You didn't cherry-pick'ed this change into 5.27 for some reason. Did you just missed that?

We bumped into exactly this problem with kwallet-pam 5.27.5

@arrowdodger I intentionally did not cherry-pick it because the previous code works around broken PAM configuration which is unfortunately present on some distros and guides. With it, pam-kwallet would stop working on those.

What problem did you bump into?

We have a pretty unusual setup and a special PAM module. At the "authenticate" stage in SDDM we cannot yet access user's $HOME, it becomes accessible during the "openSession" stage. Without this change kwallet_pan calls PAM session handler during "auth" processing.

We have a pretty unusual setup and a special PAM module. At the "authenticate" stage in SDDM we cannot yet access user's $HOME, it becomes accessible during the "openSession" stage.

That is actually fine. The auth stage in pam_kwallet only stores the password in a variable for later use and it does not need $HOME.

Hmm, so you're saying we should not pull this change into Plasma 5.27 downstream?

Hmm, so you're saying we should not pull this change into Plasma 5.27 downstream?

Not at all. If it works that's great. The only reason I didn't want it to be in 5.27 was that it might break some currently working setups.

I'd still like to know why 5.27 fails for you. I guess it's because the return pam_sm_open_session(pamh, flags, argc, argv); fails?

We see the following warnings in SDDM:

Jul  4 09:25:34 gos sddm-helper[65673]: pam_kwallet5: Couldn't create directory: /home/gleb_home/.local because: 13-Permission denied
Jul  4 09:25:34 gos sddm-helper[65673]: pam_kwallet5: Couldn't open file: /home/gleb_home/.local/share/kwalletd/gleb_home.salt because: 2-No such file or directory
Jul  4 09:25:34 gos sddm-helper[65700]: pam_kwallet5: Failed to ensure /home/gleb_home/.local/share/kwalletd/gleb_home.salt looks like a salt file
Jul  4 09:25:34 gos sddm-helper[65654]: pam_kwallet5-kwalletd: Couldn't create or read the salt file

I assumed that this was due return pam_sm_open_session(...) call during the authentication phase, when the user's home isn't yet available. However, pulling this commit in didn't fix the issue.

@arrowdodger Yeah, this commit won't make any difference. Previously it dealt with open_session being called before authenticate but that's not relevant here. It looks like your PAM setup simply places pam_kwallet before whatever makes $HOME available. If you change the order it shold work with either version.

We make $HOME available in sddm-helper's the PamBackend::openSession() method. I had an impression that it runs right before the PAM session phase. Now looking at the code I don't even see where PamHandle->openSession() gets called. Anyways, thanks for your pointers, the problem is indeed somewhere on our side.