After updating sys-libs/pam to 1.5.1_p20210610, I can no longer unlock my Plasma session. I'm always getting "Unlocking failed" error despite using the correct keyboard layout and entering the correct password. I can connect with my user just fine in a TTY. Masking 1.5.1_p20210610 and reverting to 1.5.1 immediately solves the issue.
Anything in syslog at all?
I am getting the very same behaviour with xscreensaver-6.01-r2 Logs do not contain anything special in my case: Jul 20 16:44:24 sun xscreensaver-auth[3484]: Failed login on display ":0.0" for "username" Jul 20 16:44:05 sun xscreensaver-auth[3478]: Failed login on display ":0.0" for "username" Rebuilding xscreensaver does not help. I'm using pam_ssh on top of "standard" setup (not sure if this makes any difference though).
Please provide more info, like what is in your journalctl -f (or equivalent, have no idea what non-systemd users have) logs. What are your pambase flags, auth.log entries?
(In reply to Mikle Kolyada from comment #3) > Please provide more info, like what is in your journalctl -f (or equivalent, > have no idea what non-systemd users have) logs. > > What are your pambase flags, auth.log entries? Also do you have anything in the faillock command output after login 'failure'?
Problem seems to be related to https://github.com/linux-pam/linux-pam/commit/f220cace205332a3dc34e7b37a85e7627e097e7d In my case running: chmod u-s /usr/lib64/misc/xscreensaver/xscreensaver-auth (in addition to rebuilding kernel with CONFIG_EXT4_FS_SECURITY=y followed by rebuilding pam) solved the problem.
I just hit this when trying to unlock my Plasma Wayland session (login via gdm works fine) and had to use loginctl unlock-sessions via tty to get back into my GUI. So far the only relevant looking journalctl entry is this: jūl 20 23:48:45 <hostname> kcheckpass[118989]: pam_systemd_home(kde:auth): Not a user managed by systemd-homed: No home for user <me> known which seems to have been printed for each time I almost certainly correctly entered my password.
I also hit this with sddm and no it's not related to systemd-homed. will try to debug and post here. at least for now in SDDM I can unlock existing session via 'Switch user' button.
can't find stuff in logs, not even in audit, but I see faillock counting every unlock attempt as failed login. this pam snapshot needs to be masked.
btw, it may be related to USE=audit does anyone who's affected have it enabled? post emerge --info sys-libs/pam ? I do have it enabled.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=564c63c5ab35f033187d6a531d304a1aaded5dca commit 564c63c5ab35f033187d6a531d304a1aaded5dca Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-07-21 00:20:49 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-07-21 00:21:24 +0000 profiles: mask new pam snapshot due to screen unlock issues Bug: https://bugs.gentoo.org/803050 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
I suggest that we backport the 2 libxcrypt configure/automagic and compatibility patches along with the original patch for bug 802807 to allow stabilisation in due course for the libxcrypt migration. We can figure out the precise issue with this snapshot and any libcap or other changes later.
I do not believe I have USE=audit enabled for any package (or ever enabled in kernel, IIRC). The only USE flag enabled for sys-libs/pam is filecaps. Upon retrying this after a reboot to be sure there are no stale PAM libraries and running journalctl -f, I could see that each PAM invocation seems to print that systemd-homed line (including successful login on tty), allowing it to be ruled out. More frustratingly the new log did not reveal anything obvious, since all the other messages seem to be the usual Plasma and PipeWire chatter as the active seat is taken away and then given back, so whatever is failing, does so without printing to journalctl or dmesg. ;(
(In reply to Sam James from comment #11) > I suggest that we backport the 2 libxcrypt configure/automagic and > compatibility patches along with the original patch for bug 802807 to allow > stabilisation in due course for the libxcrypt migration. > > We can figure out the precise issue with this snapshot and any libcap or > other changes later. I see no point yet. Issues collected here are totally irrelevant, only gyakovlev's concerns are possibly valid but needs proper investigation between claiming so,
(In reply to Marcin Deranek from comment #5) > Problem seems to be related to > https://github.com/linux-pam/linux-pam/commit/ > f220cace205332a3dc34e7b37a85e7627e097e7d > In my case running: > chmod u-s /usr/lib64/misc/xscreensaver/xscreensaver-auth > (in addition to rebuilding kernel with CONFIG_EXT4_FS_SECURITY=y followed by > rebuilding pam) solved the problem. but this is pam-irrelevant and have nothing for us to do. Without CONFIG_EXT4_FS_SECURITY your setcap/getcap commands are going to fail, therefore the fcaps cap_dac_override sbin/unix_chkpwd gonna fail (because this tiny program checks the /etc/shadow file on pam_unix invocation)
(In reply to Niklāvs Koļesņikovs from comment #6) > I just hit this when trying to unlock my Plasma Wayland session (login via > gdm works fine) and had to use loginctl unlock-sessions via tty to get back > into my GUI. > > So far the only relevant looking journalctl entry is this: > jūl 20 23:48:45 <hostname> kcheckpass[118989]: pam_systemd_home(kde:auth): > Not a user managed by systemd-homed: No home for user <me> known > > which seems to have been printed for each time I almost certainly correctly > entered my password. my recommendation is to log into the regular shadow account (or create one if you do not have any besides root), perform `exec login <your systemd-account>` and check `journalctl -f` output on the next console. I am running exactly the pam version in question with both shadow and homed accounts for testing, the correct auth sequence looks the following to me: """ июл 21 10:24:05 kiwi sudo[16266]: pam_systemd_home(sudo:account): Not a user managed by systemd-homed: No home for user zlogene known июл 21 10:24:05 kiwi sudo[16266]: zlogene : TTY=pts/3 ; PWD=/home/zlogene ; USER=root ; COMMAND=/bin/zsh июл 21 10:24:32 kiwi systemd-homed[1926]: zlogenez: changing state active → authenticating-for-acquire июл 21 10:24:32 kiwi systemd-homework[16331]: Provided password unlocks user record. июл 21 10:24:32 kiwi systemd-homework[16331]: Read embedded .identity file. июл 21 10:24:32 kiwi systemd-homework[16331]: Provided password unlocks user record. июл 21 10:24:32 kiwi systemd-homework[16331]: Reconciling embedded user identity completed (host and embedded version were identical). июл 21 10:24:32 kiwi systemd-homework[16331]: Everything completed. июл 21 10:24:32 kiwi systemd-homed[1926]: zlogenez: changing state authenticating-for-acquire → active июл 21 10:24:32 kiwi login[16267]: pam_systemd_home(login:auth): Home for user zlogenez successfully acquire""" As seen nothing bad happens and the following questions I have: 1.) systemd version (and USE flags used) 2.) pambase flags used 3.) homectl inspect output for your user
Created attachment 725413 [details] Test code demonstrating getspnam_r problem Attached test code demonstrates problem with getspnam_r when errno is not set to EACCES when user does not have access to /etc/shadow following manual page: The reentrant functions return zero on success. In case of error, an error number is returned. ERRORS EACCES The caller does not have permission to access the shadow password file. Running the very same code on a system with glibc-2.33-r3 / gcc-11.1.0-r2 results with (event with SUID bit set): Errno: 0 Status: 0 Result: 0 The very same code on a system with glibc-2.33-r1 / gcc-10.3.0-r2 gives: Errno: 13 Status: 13 Result: 0 and with SUID bit set: Errno: 0 Status: 0 Result: 1
Created attachment 725416 [details, diff] Potential workaround This is a workaround which worked for me (potentially there is a better solution).
(In reply to Mikle Kolyada from comment #14) > (In reply to Marcin Deranek from comment #5) > > Problem seems to be related to > > https://github.com/linux-pam/linux-pam/commit/ > > f220cace205332a3dc34e7b37a85e7627e097e7d > > In my case running: > > chmod u-s /usr/lib64/misc/xscreensaver/xscreensaver-auth > > (in addition to rebuilding kernel with CONFIG_EXT4_FS_SECURITY=y followed by > > rebuilding pam) solved the problem. > > but this is pam-irrelevant and have nothing for us to do. Without > CONFIG_EXT4_FS_SECURITY your setcap/getcap commands are going to fail, > therefore the > > fcaps cap_dac_override sbin/unix_chkpwd gonna fail (because this tiny > program checks the /etc/shadow file on pam_unix invocation) Agree although I had to mention this in case somebody ran into missing CONFIG_EXT4_FS_SECURITY=y in their kernel configuration as I did.
(In reply to Georgy Yakovlev from comment #8) > can't find stuff in logs, not even in audit, but I see faillock counting > every unlock attempt as failed login. > > this pam snapshot needs to be masked. what happens on testing unlocks with `/usr/lib64/libexec/kscreenlocker_greet --testing` ?
To recap: - systemd-homed turned out to be unrelated to this issue, sorry about the noise - as suggested by Arfrever on #gentoo-base I reverse applied https://github.com/linux-pam/linux-pam/commit/f220cace205332a3dc34e7b37a85e7627e097e7d.patch on top of the snapshot which fixed Plasma session unlock (this doesn't mean it's the cause but it's the trigger, if you will) - sounds like Marcin might be on to something - job for the toolchain team?
(In reply to Niklāvs Koļesņikovs from comment #20) > To recap: > > - systemd-homed turned out to be unrelated to this issue, sorry about the > noise > - as suggested by Arfrever on #gentoo-base I reverse applied > https://github.com/linux-pam/linux-pam/commit/ > f220cace205332a3dc34e7b37a85e7627e097e7d.patch on top of the snapshot which > fixed Plasma session unlock (this doesn't mean it's the cause but it's the > trigger, if you will) > - sounds like Marcin might be on to something - job for the toolchain team? I doubt this commit is in charge for what's going on with plasma - I am having plasma installation as well and sddm and co go flawless, though could you experiment with the command from comment#19 (just run it under your regular user you would have screensaver for, then open another console and try lock and unlock it with correct/incorrect password and then see what happens in the journalctl -f from the next console).
Created attachment 725500 [details] sanitized but complete journalctl -f output
The output from /usr/lib64/libexec/kscreenlocker_greet --testing is completely useless - just some qml and one Wayland warning that I'm sure are completely common and benign. And there's the uninterrupted excerpt from journalctl -f output during the three attempts (correct, wrong and correct passwords used): jūl 21 21:31:13 <hostname> kcheckpass[283156]: pam_systemd_home(kde:auth): Not a user managed by systemd-homed: No home for user <me> known jūl 21 21:31:18 <hostname> kcheckpass[283157]: pam_systemd_home(kde:auth): Not a user managed by systemd-homed: No home for user <me> known jūl 21 21:31:23 <hostname> kcheckpass[283158]: pam_systemd_home(kde:auth): Not a user managed by systemd-homed: No home for user <me> known Since the same line is also printed for a successful authentication via login on tty, this is just a red herring of course but it illustrates that no other output is done. ;) I've also added a log from last night that contains an actual authorization attempt with comments - as can be seen the log output is entirely useless.
(In reply to Niklāvs Koļesņikovs from comment #23) > The output from /usr/lib64/libexec/kscreenlocker_greet --testing is > completely useless - just some qml and one Wayland warning that I'm sure are > completely common and benign. > > And there's the uninterrupted excerpt from journalctl -f output during the > three attempts (correct, wrong and correct passwords used): > jūl 21 21:31:13 <hostname> kcheckpass[283156]: pam_systemd_home(kde:auth): > Not a user managed by systemd-homed: No home for user <me> known > jūl 21 21:31:18 <hostname> kcheckpass[283157]: pam_systemd_home(kde:auth): > Not a user managed by systemd-homed: No home for user <me> known > jūl 21 21:31:23 <hostname> kcheckpass[283158]: pam_systemd_home(kde:auth): > Not a user managed by systemd-homed: No home for user <me> known > > Since the same line is also printed for a successful authentication via > login on tty, this is just a red herring of course but it illustrates that > no other output is done. ;) > > I've also added a log from last night that contains an actual authorization > attempt with comments - as can be seen the log output is entirely useless. No possibly relevant information to this bug, the above means that pam_systemd_home can not grab the infromation from its NSS module, in practice it means 1. your nss is broken (unlikely) 2. your systemd-homed daemon is broken (also unlikely) 3. you are trying to auth as a user which is not managed by systemd-homed at all (most likely). That said, it is not even something "wrong" with your output, it is just not supposed to work, systemd-homed does not even try your user.
All the above does not reveal the connection between this pam snapshot in question and all the listings provided (I have also tested this snapshot on the shadow/homed/sddm systems and have not found anything related). Please open a new bug if have additional info.
I think I narrowed it to systemd (after trying a few different things too). When I downgrade systemd to 248.5 I get expected result with my test code: $ ./test Errno: 13 Status: 13 Result: 0 $ sudo ./test Errno: 0 Status: 0 Result: 1 when I upgrade to 249+ (currently 249.1) I get "unexpected" behaviour: $ ./test Errno: 0 Status: 0 Result: 0 $ sudo ./test Errno: 0 Status: 0 Result: 1 This also translates into ability of xscreensaver to unlock the screen. Can anyone else confirms this please?
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=638832d6ab501da835607d78d7949c49d5c9195b commit 638832d6ab501da835607d78d7949c49d5c9195b Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2021-07-21 19:19:37 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2021-07-21 19:21:48 +0000 profiles: unmask pam snapshot There were no evidences provided that may indicate that exactly this pam snapshot breaks anything. Referenced bug illustrates possible misconfigurations
> Can anyone else confirms this please? The test outputs "Errno: 0 Status: 0 Result: 0" for me with systemd 249.1 and dysfunctional Plasma screenlocker. The workaround patch helps.
(In reply to Eugene Shalygin from comment #28) > The test outputs "Errno: 0 Status: 0 Result: 0" for me with systemd 249.1 > and dysfunctional Plasma screenlocker. Scratch that, please, operator error. Can fully confirm your result.
I can also confirm that downgrading from systemd 249.1 to 248.5 resolves the issue with Plasma session unlocking.
something is wrong, not necessarily with pam. I've been able to unlock my screen from sddm after modifying nsswitch.conf namely lines with shadow and gshadow, I removed systemd from the lines and it works now. group: files [SUCCESS=merge] systemd gshadow: files passwd: files shadow: files so far there are several parties at play: pam: new pam breaks systemd-249's pwnam glibc: enables systemd databese in nsswitch.conf systemd: 249 introduced changes into authentication stack. here's a snippet from systemd NEWS * The userdb logic (and thus nss-systemd, and so on) now read additional user/group definitions in JSON format from the drop-in directories /etc/userdb/, /run/userdb/, /run/host/userdb/ and /usr/lib/userdb/. This is a simple and powerful mechanism for making additional users available to the system, with full integration into NSS including the shadow databases. Since the full JSON user/group record format is supported this may also be used to define users with resource management settings and other runtime settings that pam_systemd and systemd-logind enforce at login. so it looks like there were changes introduced into systemd that are incompatible with pam snapshot.
narrowed down to exact line that causes it in nsswitch.conf shadow: files systemd
I have just renewed the snapshot and removed that commit in question, but this commit is going to be a part of 1.5.2 which is in 2 weeks or so, so problem persists.
(In reply to Mikle Kolyada from comment #33) > I have just renewed the snapshot and removed that commit in question, but > this commit is going to be a part of 1.5.2 which is in 2 weeks or so, so > problem persists. If you want help debugging this further, it would be helpful to have a masked or de-keywored ebuild available so that I can reproduce the issue.
Based on comment 26, this does indeed seem to be a regression in nss-systemd. Will someone volunteer to report this upstream, or do you need me to do it? https://github.com/systemd/systemd/issues
Hmm, I guess it could be argued that nss-systemd is operating correctly here: when it doesn't find a user in its various config files, it simply returns no result without setting an error status. I think that the pam_unix code cannot rely on getting errno = EACCES from the NSS stack.
Here's a workaround for nsswitch.conf: > shadow: files [UNAVAIL=return] systemd This will cause the initial (unprivileged) call to getspname fail in libnss_files, and return immediately.
A user level work round is to use the "switch account" button on the screen lock window (kscreenlocker?). This presents the "login" screen with the account set to the current user and entering the password there (without changing the account) unlocks the screen (it doesn't create a new session for the same user.) I find it very suspicious that the screen locker can't validate the password but the login screen can. Three entered, correct, passwords also locks the login for the whole system for 10 minutes, at least with my default setup. At this point the only recovery, other than brewing a pot of coffee, is the old ck-list-sessions/ck-unlock-session stuff, which I no longer have installed for some reason.
(In reply to John Bowler from comment #38) > I find it very suspicious that the screen locker can't validate the password > but the login screen can. I would guess that the login screen runs the PAM-related code as root, whereas the lock screen runs as a different user.
For what it's worth, that workaround or life-hack only works with SDDM - GDM returns me to the same locked session, so loginctl unlock-sessions via tty or ssh is the only way for me to get back into a locked Plasma when the issue is active.
This seems to be fixed in =sys-libs/pam-1.5.1_p20210622; at least I no longer have the problem and I can't see anything other relevant changes.
(In reply to John Bowler from comment #41) > This seems to be fixed in =sys-libs/pam-1.5.1_p20210622; at least I no > longer have the problem and I can't see anything other relevant changes. Yeah, that's expected (sorry for not being clear!). We've dropped the problematic commit (we went back a commit in the snapshot), but the problem is going to end up in the next release unless the issue is fixed upstream. (Of course, now we know about the problem, we will be careful about using such a release if it makes it in there...)
After debugging and examination of the code (discussion in https://github.com/systemd/systemd/issues/20299) I believe this bug is a glibc bug and should be moved there. I mean a *gentoo* glibc bug because the actual change to nsswitch.conf is in gentoo, in the gentoo glibc patch project, not in glibc. The glibc source is here: https://sourceware.org/git/?p=glibc.git;a=summary The master nsswitch.conf is: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nsswitch.conf;h=40030d1dd7e9f7c5e09d3637988b3083bb264778;hb=refs/heads/master The glibc master does not have systemd (NameService/userdb) support. I believe the actual nsswitch.conf in gentoo comes from: https://gitweb.gentoo.org/proj/toolchain/glibc-systemd.git/ but that was cloned 6 days ago from the gentoo patched glibc, https://gitweb.gentoo.org/fork/glibc.git/. It seems mainly to be a question for that developer on the basis that a patch would have to go in to that file or to some other part of glibc (see the github discussion above.)
(In reply to John Bowler from comment #43) I would like to hear from Lennart @ systemd regarding the recommended nsswitch.conf settings. We are really just following the instructions given in nss-systemd(8).
(In reply to Mike Gilbert from comment #44) > (In reply to John Bowler from comment #43) > > I would like to hear from Lennart @ systemd regarding the recommended > nsswitch.conf settings. We are really just following the instructions given > in nss-systemd(8). +1 on that; the nss-systemd man page says this: >This module also ensures that the root and nobody users and groups >(i.e. the users/groups with the UIDs/GIDs 0 and 65534) remain >resolvable at all times, even if they aren't listed in /etc/passwd or >/etc/group, or if these files are missing. I believe the [unavail=return] setting will fire if /etc/shadow is missing, but the fabricated information returned without the change by getspnam (the password change information) is unreliable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/toolchain/glibc-systemd.git/commit/?id=0854e4aa76942758f676dbca6dd1388c049b0149 commit 0854e4aa76942758f676dbca6dd1388c049b0149 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-07-29 15:23:09 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-07-29 16:49:02 +0000 Return immediately if libnss_files cannot open /etc/shadow This restores the EACCES errno value that is expected by pam_unix in >=sys-libs/pam-1.5.2. Bug: https://bugs.gentoo.org/803050 Signed-off-by: Mike Gilbert <floppym@gentoo.org> Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> gentoo-config/nsswitch.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e3e113d909c2ba213d033fad3e8e531f40e75122 commit e3e113d909c2ba213d033fad3e8e531f40e75122 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-07-29 16:51:28 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-07-29 16:51:41 +0000 sys-libs/glibc: Add PAM fix to live ebuild Bug: https://bugs.gentoo.org/803050 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/Manifest | 2 +- sys-libs/glibc/glibc-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=985aba7f10363d29ea3b5632ffe00ce1ce92ba89 commit 985aba7f10363d29ea3b5632ffe00ce1ce92ba89 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-08-14 20:01:31 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-08-14 20:07:57 +0000 sys-libs/glibc: Update default nsswitch.conf in 2.33, again Bug: https://bugs.gentoo.org/803050 Bug: https://github.com/linux-pam/linux-pam/issues/379 Bug: https://github.com/systemd/systemd/issues/20299 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/Manifest | 1 + sys-libs/glibc/glibc-2.33-r6.ebuild | 1551 +++++++++++++++++++++++++++++++++++ 2 files changed, 1552 insertions(+)
1.5.2 is actually ok, it has all the fixes.
