I have an issue that I suspect is caused by a recent glibc change, but I haven't 100% ruled out another cause, so this report might be bogus. I use PHP-FPM [1] with chroots enabled. Since upgrading glibc, name resolving (via DNS) fails with "getaddrinfo failed: System error" in my chroot and I'm pretty sure it is caused by the recently added "Block attempts to dlopen any module we haven't already opened" [2] What seems to happen is that the PHP-FPM master process only loads libnss_files.so.2 and libnss_systemd.so.2 because it uses that to resolve the username (it matches nsswitch which contains: "passwd: files systemd") If any of the FPM workers then attempts to perform dns resolving, that fails because libnss_dns.so.2 has not been loaded yet (even though I made it available in the chroot), and due to the recent change, it won't be loaded either. I have confirmed I can "fix" it by forcing the fpm master to load the dns module by modifying nsswitch.conf outside of the chroot to contains "passwd: dns files systemd", this fixes it 1. https://www.php.net/manual/en/install.fpm.php 2. https://github.com/bminor/glibc/commit/429029a73ec2dba7f808f69ec8b9e3d84e13e804#diff-9305f1992144bc8c923a840d44827642f1c3f57e3df85a69357fff2fe7370fb8R352
Some more information for clarification: # grep dns /etc/nsswitch hosts: files dns # strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22 openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22 openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22 # curl https://localhost/test.php getaddrinfo failed: System error -- # grep dns /etc/nsswitch passwd: dns files systemd hosts: files dns # strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22 openat(AT_FDCWD, "/usr/lib/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 22 openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22 openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22 # curl https://localhost/test.php works
I've started a discussion on libc-alpha: NSS chroot protection https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html
(In reply to Florian Weimer from comment #2) > I've started a discussion on libc-alpha: > > NSS chroot protection > https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html Can you link to more context on what security regressions this change was meant to address? chrooted servers have been running for decades using the NSS databases of the chroot jail, and this change breaks all of them.
It's CVE-2019-14271: https://nvd.nist.gov/vuln/detail/CVE-2019-14271 (The Docker fix is likely incomplete depending on nsswitch.conf contents.) That issue is of no concern once the service is running, it applies to the construction of the chroot contents from the outside.
Fixed for 2.34. Also backported to 2.33. commit 58673149f37389495c098421085ffdb468b3f7ad Author: DJ Delorie <dj@redhat.com> Date: Thu Feb 18 15:26:30 2021 -0500 nss: Re-enable NSS module loading after chroot [BZ #27389] The glibc 2.33 release enabled /etc/nsswitch.conf reloading, and to prevent potential security issues like CVE-2019-14271 the re-loading of nsswitch.conf and all mdoules was disabled when the root filesystem changes (see bug 27077). Unfortunately php-lpfm and openldap both require the ability to continue to load NSS modules after chroot. The packages do not exec after the chroot, and so do not cause the protections to be reset. The only solution is to re-enable only NSS module loading (not nsswitch.conf reloading) and so get back the previous glibc behaviour. In the future we may introduce a way to harden applications so they do not reload NSS modules once the root filesystem changes, or that only files/dns are available pre-loaded (or builtin). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Just as a note, the change has also broken postfix. Its smtp client enters chroot after start, and then down the road calls `getservbyname()` which fails.