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

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

[Arjun Shankar]

Hi all,

I have been working on a fix for bug 27959 ([1], "glibc 2.33 NSS
refactoring lost static NSS support") that involves getting rid of
"--enable-static-nss" entirely and instead moves the decision of
allowing/disallowing dlopen to application build-time. The solution I
was trying to arrive at was:

Statically linked applications that are built "as usual" continue to
behave like they do currently, which is: except for the built-in
"files" and "dns" backends, any other backends configured via
nsswitch.conf *do* lead to the statically linked application
dlopen'ing the corresponding module. However, for applications that
want to avoid having nss related dlopen calls, a new statically linked
library is provided by glibc - say "libnss_nodlopen.a". The archive
would contain just enough of an alternative dlopen-free nss
implementation that compiling with something like:

$CC -static libnss_nodlopen.a application.c

...leads to the linker picking the alternative implementation of nss
functions that are involved in loading nss modules from the new
archive instead of libc.a -- and these wouldn't dlopen. Presumably,
any non-built-in modules configured in nsswitch.conf get treated as if
the corresponding service was unavailable during the call.

Florian referred to this sort of solution back when he moved the
"files" backend into libc [2]. I have been in touch with him and
asking him questions about this topic as I work through this problem.

I started by compiling an additional copy of nss/nss_module.c - the
code that is responsible for module loading. The second copy, through
some macros, avoids calling dlopen. My initial understanding was that
this would be sufficient content in the "new" libnss_nodlopen.a and if
it were provided first on the command line, the linker would prefer
the implementations from there when resolving nss related references
(e.g. "__nss_module_get_function"). This should lead to the
application having no dlopen calls in the statically linked
executable.

This isn't what actually happens. The linker presumably first notes
that the application calls, say "getpwent", then doesn't manage to
resolve that reference until it arrives at libc.a. At that point,
internal functions referred to by "getpwent" going up the nss call
stack *all* get picked from libc.a, i.e. the libc.a copy of
"__nss_module_get_function" gets picked up, and not the one in the
"new" archive I was producing.

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.

How reasonable does that sound as a solution? What other alternatives
are there? Another way of tackling this could be changing the default
so that libc.a doesn't call dlopen for nss and making the dlopen
version optional instead -- presumably via a similar statically linked
library that *does* use dlopen.

Cheers!

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27959
[2] https://sourceware.org/pipermail/libc-alpha/2021-June/127273.html

-- 
Arjun Shankar
he/him/his

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

[Florian Weimer]

* 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?

Thanks,
Florian

Re: [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.

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

[Florian Weimer]

* 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.


I don't see any implementations of NSS-related interfaces in resolv/,
they are in inet/.  I do not think we need to move resolv/nss_dns (or
hesiod) because those are plug-ins that can be built anymore.  Only
gethostbyname, getaddrinfo etc. need to be moved.

I think nss/ is actually fine as a directory name because some NSS
functions (getservbyname, for example) are not concerned with identity
management.  Even claiming that getaddrinfo is about IdM is a bit of a
stretch.

For backporting, it's probably best if all commits (one per directory
perhaps) go into the tree at the same time.

It looks like the directories that need to be moved are grp, gshadow,
parts of inet, the getaddrinfo functionality in posix/, pwd/, and
shadow/.  The sunrpc/ compat bits can remain there, I think—they are
already missing from libc.a, so those parts do not interfere with
Arjun's project.

Thanks,
Florian