[RFC] Avoiding dlopen in statically linked applications that use nss [#27959]

[Carlos O'Donell]

On 6/1/23 01:40, Florian Weimer via Libc-alpha wrote:
> * Arjun Shankar via Libc-alpha:
> 
>> Therefore, if my understanding of the situation is correct, this new
>> statically linked library will need to have more bits from nss
>> including all public functions available for name resolution in order
>> for it to work. I expect this would also mean moving code from various
>> places in the glibc source tree into nss/ (e.g. pwd/, resolv/, grp/
>> etc.) so that they can then be included in the new library.
> 
> I'm not opposed to this change (moving pwd, grp, gethostbyname,
> getaddrinfo etc. into nss/) as a general simplification and build
> speedup.  It's actually unrelated to the static NSS changes.
> 
> What do others think?

I am not opposed to it, but in order to ensure that backports have clear line in
the sand we should move everything, including nss/ pwd/ resolv/ grp/ into a new
directory e.g. idm/ (or something) to indicate that the intent of the directory
is to try to contain all the identity management functions along with their 
required NSS infrastructure. This way if during a backport the patch application
fails it's because nss/ hasn't been renamed yet and you know you should do those
patches first.

Subjectively I think we have too many directories with not many files inside of
them, so coalescing these into a new top-level directory makes sense to me and
brings all the benefits you talk about.

I agree it is unrelated to the static NSS changes whose implementation may just
be solved by a different technical solution.

So this directory refactor gets a +1 from me.

I would like to hear Andreas' input here since he has worked extensively on
all of this code.

-- 
Cheers,
Carlos.