Don't try to dlopen() built-in NSS types

[trasz]

Summary

Don't call dlopen(3) for the built-in NSS types - "cache", "compat",
"dns", "files", "db", and "nis". It saves some path lookups during
binary startup.

[markj]

If someone actually created dynamic NSS modules with these names today, would they work? Or is there some reason that would fail? If it works, then this change would break such a configuration, though I'd be surprised if anyone actually does that. At the very least, we should document these names as being reserved by the implementation.

[trasz]

As it is now, I believe they could work in FreeBSD. In Linux, glibc already provides the built-in modules as shared libraries, so it would clash there. I've grepped the ports tree for '\<nss_.*so', and I don't see an example of anyone doing that.

Which is to say: I believe it would be rather silly thing to try install a third-party module with a name of a built-in source.

[markj]

In D17557#374794, @trasz wrote:

As it is now, I believe they could work in FreeBSD. In Linux, glibc already provides the built-in modules as shared libraries, so it would clash there. I've grepped the ports tree for '\<nss_.*so', and I don't see an example of anyone doing that.

Which is to say: I believe it would be rather silly thing to try install a third-party module with a name of a built-in source.

I completely agree, but stranger things have happened. I would just suggest adding a sentence to this effect to nsdispatch(3) or nsswitch.conf(5).

[markj]

lib/libc/net/nsdispatch.c

491

Sorry, meant to leave this comment with the review: we should use the NSSRC_CACHE, etc. constants defined in nsswitch.conf.

[trasz]

Changes suggested by markj@.

[markj]

Thanks