force-init of nsswitch modules?
Florian Weimer
fw@deneb.enyo.de
Sun Dec 22 11:28:28 GMT 2024
* Michael Tokarev:
> 21.12.2024 22:01, Florian Weimer
>
>> <https://sourceware.org/pipermail/libc-alpha/2021-February/122737.html>
>
> HMM Wait...
>
> > In order to avoid security regressions, we disabled reloading of
> > /etc/nsswitch.conf after the chroot has changed. We also went a step
> > further and disabled loading additional NSS modules based on the
> > *current* loaded configuration.
>
> Do I understand it correctly that libnss modules are currently useless
> to have in chroot, because their loading is disabled if a different
> root dir is detected?
No, that was disabled because it had too much adverse impact.
Bit this change has happened since:
| In a future glibc version, we could perhaps move files & dns into
| libc.so.6, and reenable the load-inhibition feature for other modules
| (that aren't files or dns).
So we could re-enable the chroot hardening.
> HMM. This simplifies chroot setup *greatly*, and, at the same time,
> breaks some stuff.. Interesting...
>
> And how about libnss_dns.so.2, libnss_files.so.2 - are they always
> present in libc.so.6 as built-ins?
Yes, that change landed in glibc 2.34.
> Because it looks like I've some inconsistent results. A program
> does getpwnam() lookup (so it reads nsswitch.conf et al), next it
> does chroot(), and next it performs some DNS lookup or getaddrinfo()
> call (for the first time during runtime, and this first time being
> in chroot already - so if libnss_dns.so were a module, it hasn't
> been loaded yet). And the DNS (and /etc/hosts) lookup actually
> works without loading libnss_dns.so.2!
I think that's the expected behavior with glibc 2.34. The
libnss_dns.so.2 file is still there, but it is mostly empty.
More information about the Libc-help
mailing list