screen unlocking broken by recent pam changes (in most lockers)

[peterhoeg]

Describe the bug

Unlocking plasma wayland sessions fails:

unix_chkpwd[10350]: check pass; user unknown
unix_chkpwd[10351]: check pass; user unknown
unix_chkpwd[10351]: password check failed for user (peter)
kcheckpass[10349]: pam_unix(kde:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=peter

Logging in with the same password works perfectly fine.

Steps To Reproduce

1. run latest unstable
2. start KDE wayland session
3. login
4. lock screen
5. try to unlock with the correct password

Expected behavior

Unlocking works as normal.

Additional context

Looks like 0715ef5 is to blame.

Notify maintainers

@NixOS/qt-kde and @winterqt

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.16.2, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.5.1`
 - channels(peter): `"home-manager"`
 - nixpkgs: `/home/peter/src/active/nixpkgs_unstable`

[KFearsoff]

I also experience this bug, running Sway with Swaylock.

[stigtsp]

Same problem with xsecurelock and i3lock

[x10an14]

I found this issue ticket which helped fix it for me.

Since I install swaylock (and sway) through home-manager, I just went with the security.pam.services route.

[winterqt]

Very sorry for causing this issue.

#156974 seems to be working as a fix, at the cost of doing a mass rebuild. If anyone here wants to try and see if it fixes their issue, please let us know the results.

[LunNova]

loginctl unlock-session works to unlock a running plasma session with this issue.

[danth]

Can confirm this affects i3lock on XMonad also

[MasseR]

Can confirm this affects xsecurelock on XMonad, on three separate machines.

[jpotier]

xsecurelock on XMonad as well, I've got the following in my logs:

Jan 30 09:25:32 kktdr unix_chkpwd[1348786]: check pass; user unknown
Jan 30 09:25:35 kktdr unix_chkpwd[1348790]: check pass; user unknown
Jan 30 09:25:35 kktdr unix_chkpwd[1348790]: password check failed for user (eeva)
Jan 30 09:25:35 kktdr authproto_pam[1348785]: pam_unix(login:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser=eeva rhost=localhost  user=eeva
Jan 30 09:25:37 kktdr unix_chkpwd[1348794]: check pass; user unknown
Jan 30 09:25:40 kktdr unix_chkpwd[1348798]: check pass; user unknown
Jan 30 09:25:40 kktdr unix_chkpwd[1348798]: password check failed for user (eeva)
Jan 30 09:25:42 kktdr unix_chkpwd[1348801]: check pass; user unknown
Jan 30 09:25:44 kktdr unix_chkpwd[1348810]: check pass; user unknown
Jan 30 09:25:44 kktdr unix_chkpwd[1348810]: password check failed for user (eeva)
Jan 30 09:25:46 kktdr xss-lock[1348785]: 2022-01-30T07:25:46Z 1348785 xsecurelock: pam_authenticate: Authentication failure.

seems pretty close

(and also, I saw this was patched already)

[oxalica]

KDE X11 session also suffers from this issue. I think we can remove wayland keyword in the title.

[asymmetric]

Is there a NixOS test that could’ve caught this?

[vcunat]

I don't think there is. Also, note that most of the tests that we have are not channel blockers (the tested job).

[Lillecarl]

 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.12-xanmod1-tt, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.5.1`
 - channels(root): `"unstable-22.05pre343944.ff377a78794, nixos-hardware, nixos-21.11.335037.e67c94a1adb, master"`
 - channels(lillecarl): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Confirmed, KDE X11

[mohe2015]

I think we have enough confirmation, we're waiting on #157215 getting merged

[andrevmatos]

Meanwhile, one can use an overlay and rebuild only the needed packages:
e.g.:

• Download suid-wrapper-path.patch from above PR and save it in the overlay folder

final: prev: let
  pam = prev.pam.overrideAttrs (attrs: {
    patches = [ ./suid-wrapper-path.patch ];
  });
in {
  plasma5Packages = prev.plasma5Packages.overrideScope' (
    finalx: prevx: {
      plasma5 = prevx.plasma5.overrideScope' (
        finaly: prevy: {
          kscreenlocker = prevy.kscreenlocker.override { inherit pam; };
        }
      );
    }
  );
}

[vcunat]

Also nixos-unstable channel updated now to 554d2d8aa25, so all these should be resolved. (You can now still get redirected to older channel version due to CDN front-end caching, though hopefully that should expire soon.)

[stigtsp]

Tyvm for fixing this issue, works for me. :-)

[x10an14]

I found this issue ticket which helped fix it for me.

Since I install swaylock (and sway) through home-manager, I just went with the security.pam.services route.

My issue has only worsened, however... I'll debug it closer later when I get a chance, but I can no longer unlock swaylock. Even with the abovementioned work-around.

I now have to log into another TTY and kill swaylock from there. Would you prefere I don't continue this in this issue?

[jvanbruegge]

I use swaylock as well and with this fix it works normally again

[x10an14]

I use swaylock as well and with this fix it works normally again

After much testing I still have the same issue, both with and without the pam fix I referenced in my first post.
I keep getting this line in my swaylog:

[pam.c:101] pam_authenticate failed: invalid credentials

I suppose I'll make a new issue since others (@jvanbruegge) says this works for them.

[vcunat]

@x10an14: what do you mean by "this fix"? The best way now should be simply to update, without any explicit fixes. (typical version in my last post)

[x10an14]

(...) The best way now should be simply to update, without any explicit fixes. (typical version in my last post)

I've done that, to no avail. Currently at commit 554d2d8aa25b6e583575459c297ec23750adb6cb.

@x10an14: what do you mean by "this fix"? (...)

I found #143365 which helped fix it for me.

Now I no longer can, ref: #158025

[primeos]

Is there a NixOS test that could’ve caught this?

Thanks to @Synthetica9 there is one now: #158027
And the Sway test is a channel blocker so this should avoid regressions like this one in the future.

I've verified that it does at least catch this particular regression:

554d2d8 (a good revision): Test passes.

efeefb2 (a bad revision): Test fails (timeout):

[...]
machine: waiting for failure: pgrep -x swaylock
machine # [  137.559190] unix_chkpwd[1343]: check pass; user unknown
machine # [  137.560995] unix_chkpwd[1343]: password check failed for user (alice)
machine # [  137.564510] swaylock[1327]: pam_unix(swaylock:auth): authentication failure; logname=alice uid=1000 euid=1000 tty= ruser= rhost=  user=alice
[...]
Exception: action timed out after 900 seconds

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/i3lock-on-nixos-via-home-manager-authentication-failure/17540/3