Bug#1003342: libc6: NIS client not working after update to libc6:amd64 2.33-1

[Nuno Oliveira]

Package: libc6
Version: 2.33-1
Severity: normal

Hi,

After the update of libc6 2.32-5 -> 2.33-1, NIS users are not recognized
by the system anymore. The NIS setup was working OK before this upgrade,
which just included (according to aptitude):

REMOVE (PURGE)] libjson-c4:amd64 0.13.1+dfsg-9
[UPGRADE] glibc-doc:amd64 2.32-5 -> 2.33-1
[UPGRADE] glibc-doc-reference:amd64 2.32-1 -> 2.33-1
[UPGRADE] libc-bin:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc-dev-bin:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc-l10n:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dbg:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev-i386:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev-x32:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-i386:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-x32:amd64 2.32-5 -> 2.33-1
[UPGRADE] locales:amd64 2.32-5 -> 2.33-1
[UPGRADE] nscd:amd64 2.32-5 -> 2.33-1
==

"ypcat passwd" works fine, as before. "finger username" does not work.
The system has libnss-nis and libnss-nisplus previously installed. The
usual usual instructions in /usr/share/doc/nis/nis.debian.howto.gz were
verified and they are still implemented as suggested (no changes). This
happens on multiple client systems, where the behavior seems to be
reproducible. "ypwhich" works normally.

Doing a "strace finger username" and checking the differences between a
working system (still libc6 2.32-5) and a nonworking system (with libc6 2.33-1):

In the old system, after

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
...
close(3)

there is a call to

openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
...
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
...
close(3)

In the updated system (libc6 2.32-5), after the call to
libnss_compat.so.2, there is no following call to libnss_nis.so.2 or
/etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists,
and points to libnss_nis.so.2.0.0.

I can provide more information, if necessary.

Thanks for looking into this,

Nuno.


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (700, 'testing'), (650, 'unstable'), (610, 'stable-security'), (600, 'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/24 CPU threads)
Locale: LANG=pt_PT.UTF8, LC_CTYPE=pt_PT.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to pt_PT.UTF8), LANGUAGE=pt:pt_BR:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii libgcc-s1 11.2.0-13

Versions of packages libc6 recommends:
ii libidn2-0 2.3.2-2

Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.79
ii glibc-doc 2.33-1
ii libc-l10n 2.33-1
ii libnss-nis 3.1-4
ii libnss-nisplus 1.3-4
ii locales 2.33-1

-- debconf information:
glibc/disable-screensaver:
* glibc/restart-services: smbd ssh exim4 cups cron atd
glibc/kernel-not-supported:
* libraries/restart-without-asking: false
* glibc/upgrade: true
glibc/restart-failed:
glibc/kernel-too-old:

[Aurelien Jarno]

Hi,

I guess you mean 2.33-1 here.

> libnss_compat.so.2, there is no following call to libnss_nis.so.2 or
> /etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists,
> and points to libnss_nis.so.2.0.0.

Thanks for the detail analysis. I can confirm the same issue. It has
been fixed by this upstream commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=9b456c5da968ee832ea4b2b73a18a5bf6d2118a6

Unfortunately, due to symbols changes, it is not backportable to glibc
2.33 easily without potentially breaking other NSS modules during
upgrade.

On the other hand, the problem is already fixed in glibc 2.34 (currently
in experimental), so the easiest fix might be to get glibc 2.34 ready to
be uploaded to unstable.

Regards,
Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net

[Nuno Oliveira]

* Aurelien Jarno <aure...@aurel32.net> [2022-01-09 22:59]:

Hi Aurelien,

I can also confirm that this bug is not present in 2.34-0experimental2.

Thanks for the help,

Nuno.