With automatic reloading, /etc/nsswitch.conf from the chroot is picked up by NSS calls. This can easily cause loading arbitrary DSOs from the chroot, which is probably not what was intended. It may be best to avoid loading anything NSS-related if / has changed since the first loading of /etc/nsswitch.conf.
Fixed in 429029a73ec2dba7f808f69ec8b9e3d84e13e804
In glibc 2.32 I had chroot and no nscd process on the host (neither outside chroot, nor within chroot). In glibc 2.33 somehow I am forced to have nscd and therefore (mount -B) /var/run/nscd/socket within the chroots. I suspect that this change effectively forces the presence of nscd for the chrooted environments, which is a regression.
(In reply to dilyan.palauzov@aegee.org from comment #2) > In glibc 2.32 I had chroot and no nscd process on the host (neither outside > chroot, nor within chroot). In glibc 2.33 somehow I am forced to have nscd > and therefore (mount -B) /var/run/nscd/socket within the chroots. > > I suspect that this change effectively forces the presence of nscd for the > chrooted environments, which is a regression. You can probably work around this issue by preloading libnss_files.so.2 and perhaps libnss_dns.so.2, so that they get loaded immediately, outside of the chroot.
As far as I can see I had in the chrooted environment libnss_dns and libnss_files from libc 2.23 (twenty three). I have just upgraded libc the outside of chroot and libc in the chroot was unchanged (for very long time). After upgrading to libc 2.33 this configuration stopped working. Eventually I started nscd, bind-mounted var/run/nscd within the chroot and this helped. What I am saying is that this change, or something else between 2.32 and 2.33 causes a regression: a workflow which was working with 2.32 (no nscd daemon in chroot) is not working anymore with 2.33. As such the regression, if intended, shall be spelled clearly.
Mixing NSS providers between the host and guest is what we're trying to avoid, as we consider that a security issue[*] - a container management tool, for example, may not be able to trust the config/modules inside the container and should continue using the hosts' modules and nsswitch.conf. Programs which "enter" chroots/containers should exec() some in-chroot program, which would then load that nsswitch.conf. If you have such a management tool, you should ensure your NSS environment is complete by calling suitable API functions (like getpwuid) to ensure each NSS provider is loaded, before chrooting. [*] for example, of a container had some custom nss modules defined in nsswitch.conf, and those custom modules took advantage of the host tool's priviledges.
I filled: • https://bugs.php.net/bug.php?id=80756 for PHP, and • https://bugs.openldap.org/show_bug.cgi?id=9466 for OpenLDAP
FYI I reported https://sourceware.org/bugzilla/show_bug.cgi?id=27389 because I considered this to be a bug. I also think this change should be more prominent in the changelog as it breaks things that used to work fine by considering legitimate uses as suddenly being a security risk
The master branch has been updated by DJ Delorie <dj@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=58673149f37389495c098421085ffdb468b3f7ad 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>
The release/2.33/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3e880d733753183696d1a81c34caef3a9add2b0c commit 3e880d733753183696d1a81c34caef3a9add2b0c 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> (cherry picked from commit 58673149f37389495c098421085ffdb468b3f7ad)