Hi,
On 2022-01-08 17:15, Nuno Oliveira wrote:
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
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.