Right now, long running processes don't get updates to the nsswitch module list in /etc/nsswitch.conf if nscd isn't running. This is because libc caches the module list in memory after it's initially read. It would be useful if there was a nss_init() call akin to res_init() that would flush the cached list and reload it. A relevant downstream bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=621700 In that case the long running process was GDM (graphical login screen). A user used authconfig to change their nsswitch.conf and then used fast user switching (which jumps to a login screen on a different vt) to try to test the new configuration. Because the login screen was around before the user ran authconfig, the list of nsswitch modules was stale. This caused a getpwnam() call to fail, which ultimately lead to login failure. I worked around this for the above bug report by spawning a helper program to do the getpwnam() call for me.
A more reasonable proposition would be add timestamp and reload when more cache is older than 5 minutes.
so i believe the stub resolver doesn't require res_init anymore to get changes in /etc/resolv.conf, so I'd like to to update this report to request that changes in /etc/nsswitch.conf get updated immediately too :-)
Patches for implementing reloading of nsswitch.conf are under review: https://sourceware.org/pipermail/libc-alpha/2020-July/115678.html
great news, thanks!
This has been implemented in glibc 2.33. Related commits follow. Note that some fixes are required as well. commit f4f3b09111e9fa38fd485979a3e40b6cfa6a757d Author: DJ Delorie <dj@redhat.com> Date: Mon Nov 9 22:09:34 2020 -0500 nsswitch: use new internal API (callers) Stitch new ABI and types throughout all NSS callers. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit 6eceded941bb6dcc097291757e2aef5cd7212133 Author: DJ Delorie <dj@redhat.com> Date: Mon Nov 9 22:08:04 2020 -0500 nsswitch: user new internal API (tests) Testsuite support and new test for new API. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit f8847d83e17774ed5e9c0f75ef693680b91bcae4 Author: DJ Delorie <dj@redhat.com> Date: Mon Nov 9 22:06:57 2020 -0500 nsswitch: use new internal API (core) Core changes to switch the NSS internals to use the new API. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit fa78feca47fdc226b46e7f6fea4c08c10fccd182 Author: Florian Weimer <fweimer@redhat.com> Date: Thu Feb 20 13:20:32 2020 +0100 nss: Implement <nss_database.h> This code manages the mappings of the available databases in NSS (i.e. passwd, hosts, netgroup, etc) with the actions that should be taken to do a query on those databases. This is the main API between query functions scattered throughout glibc and the underlying code (actions, modules, etc). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit fd5b9b4458ef662d1955459e22a11b15d16a5648 Author: Florian Weimer <fweimer@redhat.com> Date: Thu Feb 20 09:32:27 2020 +0100 <nss_action.h>: New abstraction for combining NSS modules and NSS actions nss_action manages a set of lists of actions; these are the portions of the lines in nsswitch.conf to the right of the colons, like "dns [!UNAVAIL=return] files". Each permutation of actions and conditionals is cached for reuse, which limits memory growth, and refers to the static list of modules managed by nss_modules. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> commit 171689dac7fcb979e7d3ffbd307eacae3c07c2d3 Author: Florian Weimer <fweimer@redhat.com> Date: Wed Feb 19 20:55:48 2020 +0100 nss: Introduce <nss_module.h> This provides the struct nss_module type, which combines the old struct service_library type with the known_function tree, by statically allocating space for all function pointers. struct nss_module is fairly large (536 bytes), but it will be shared across NSS databases. The old known_function handling had non-some per-function overhead (at least 32 bytes per looked-up function, but more for long function anmes), so overall, this is not too bad. Resolving all functions at load time simplifies locking, and the repeated lookups should be fast because the caches are hot at this point. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>