Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 803050 - sys-libs/pam 1.5.2(?), sys-apps/systemd-249.1: nss incompatibilities
Summary: sys-libs/pam 1.5.2(?), sys-apps/systemd-249.1: nss incompatibilities
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal with 1 vote (vote)
Assignee: Mikle Kolyada
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-20 14:32 UTC by ut2s7kol87
Modified: 2021-09-16 17:24 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Test code demonstrating getspnam_r problem (test.c,555 bytes, text/x-csrc)
2021-07-21 08:22 UTC, Marcin Deranek
Details
Potential workaround (workaround.patch,433 bytes, patch)
2021-07-21 08:24 UTC, Marcin Deranek
Details | Diff
sanitized but complete journalctl -f output (journalctl-f.txt,8.99 KB, text/plain)
2021-07-21 18:39 UTC, Niklāvs Koļesņikovs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ut2s7kol87 2021-07-20 14:32:05 UTC
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.
Comment 1 Sam James archtester gentoo-dev Security 2021-07-20 14:41:57 UTC
Anything in syslog at all?
Comment 2 Marcin Deranek 2021-07-20 15:02:35 UTC
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).
Comment 3 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-20 15:15:50 UTC
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?
Comment 4 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-20 17:47:19 UTC
(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'?
Comment 5 Marcin Deranek 2021-07-20 17:54:02 UTC
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.
Comment 6 Niklāvs Koļesņikovs 2021-07-20 21:03:40 UTC
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.
Comment 7 Georgy Yakovlev gentoo-dev 2021-07-20 23:28:31 UTC
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.
Comment 8 Georgy Yakovlev gentoo-dev 2021-07-20 23:57:45 UTC
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.
Comment 9 Georgy Yakovlev gentoo-dev 2021-07-21 00:06:26 UTC
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.
Comment 10 Larry the Git Cow gentoo-dev 2021-07-21 00:21:42 UTC
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(+)
Comment 11 Sam James archtester gentoo-dev Security 2021-07-21 03:54:44 UTC
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.
Comment 12 Niklāvs Koļesņikovs 2021-07-21 04:13:10 UTC
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. ;(
Comment 13 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 06:53:48 UTC
(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,
Comment 14 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 07:18:31 UTC
(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)
Comment 15 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 07:29:19 UTC
(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
Comment 16 Marcin Deranek 2021-07-21 08:22:16 UTC
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
Comment 17 Marcin Deranek 2021-07-21 08:24:04 UTC
Created attachment 725416 [details, diff]
Potential workaround

This is a workaround which worked for me (potentially there is a better solution).
Comment 18 Marcin Deranek 2021-07-21 09:07:07 UTC
(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.
Comment 19 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 09:38:04 UTC
(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` ?
Comment 20 Niklāvs Koļesņikovs 2021-07-21 13:18:32 UTC
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?
Comment 21 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 13:27:09 UTC
(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).
Comment 22 Niklāvs Koļesņikovs 2021-07-21 18:39:41 UTC
Created attachment 725500 [details]
sanitized but complete journalctl -f output
Comment 23 Niklāvs Koļesņikovs 2021-07-21 18:40:09 UTC
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.
Comment 24 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 19:00:44 UTC
(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.
Comment 25 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 19:24:51 UTC
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.
Comment 26 Marcin Deranek 2021-07-21 19:44:09 UTC
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?
Comment 27 Arfrever Frehtes Taifersar Arahesis 2021-07-21 20:29:46 UTC
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
Comment 28 Eugene Shalygin 2021-07-21 21:07:50 UTC
> 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.
Comment 29 Eugene Shalygin 2021-07-21 21:17:17 UTC
(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.
Comment 30 Niklāvs Koļesņikovs 2021-07-21 22:05:25 UTC
I can also confirm that downgrading from systemd 249.1 to 248.5 resolves the issue with Plasma session unlocking.
Comment 31 Georgy Yakovlev gentoo-dev 2021-07-22 01:36:00 UTC
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.
Comment 32 Georgy Yakovlev gentoo-dev 2021-07-22 01:48:03 UTC
narrowed down to exact line that causes it in nsswitch.conf


shadow:     files systemd
Comment 33 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-07-22 06:54:52 UTC
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.
Comment 34 Mike Gilbert gentoo-dev 2021-07-22 16:59:34 UTC
(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.
Comment 35 Mike Gilbert gentoo-dev 2021-07-22 17:23:36 UTC
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
Comment 36 Mike Gilbert gentoo-dev 2021-07-22 17:36:36 UTC
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.
Comment 37 Mike Gilbert gentoo-dev 2021-07-22 17:40:19 UTC
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.
Comment 38 John Bowler 2021-07-22 20:14:19 UTC
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.
Comment 39 Mike Gilbert gentoo-dev 2021-07-22 20:29:18 UTC
(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.
Comment 40 Niklāvs Koļesņikovs 2021-07-22 20:50:55 UTC
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.
Comment 41 John Bowler 2021-07-24 22:46:41 UTC
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.
Comment 42 Sam James archtester gentoo-dev Security 2021-07-24 22:48:31 UTC
(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...)
Comment 43 John Bowler 2021-07-28 19:05:47 UTC
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.)
Comment 44 Mike Gilbert gentoo-dev 2021-07-28 19:25:42 UTC
(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).
Comment 45 John Bowler 2021-07-28 21:22:40 UTC
(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.
Comment 46 Larry the Git Cow gentoo-dev 2021-07-29 16:49:23 UTC
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(-)
Comment 47 Larry the Git Cow gentoo-dev 2021-07-29 16:51:52 UTC
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(-)
Comment 48 Larry the Git Cow gentoo-dev 2021-08-14 20:08:08 UTC
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(+)
Comment 49 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2021-09-16 17:24:28 UTC
1.5.2 is actually ok, it has all the fixes.