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