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. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
