Re: What to do when glibc environment variables or tunables conflict?

[Siddhesh Poyarekar <siddhesh at gotplt dot org>]

On 06/02/20 03:42, Carlos O'Donell wrote:
> Explicit use of LD_BIND_NOW=1 or LD_DEBUG=unused disables ld audit
> because both uses set GLRO(dl_lazy) to zero and disable lazy binding

LD_DEBUG doing that is a bug.  If th binary is built with lazy binding
(and LD_BIND_NOW is not set) it should simply warn that 'unused' is
unavailable for lazy binding.

> entirely. The ld audit interface requires the ld lazy binding hook
> to perform various auditing activities. In the future, after refactoring,
> we should be able to support all of LD_AUDIT with the exception of PLT
> enter/exit (which has questionable value).
> 
> What should happen here?
> 
> Which env vars should override other env vars?
> 
> Should env vars override options built into a binary?
> 
> For example if the auditor is enabled via DT_AUDIT (a feature which
> we are going to add) should LD_BIND_NOW or LD_DEBUG=unused disable it?
> 
> I would like to suggest the following axioms:
> 
> (A1) Consistent results should be produced regardless of env var order
>      or tunable order.
> 
> (A2) Where multiple variables conflict we should pick a winner and consider
>      hard failing where users require a specific semantic behaviour.
> 

Agreed, this would mean maintaining and documenting a hierarchy of
tunables/envvars in the same namespace.  Tunables in different
namespaces ought to not conflict, but I haven't looked at all of them to
authoritatively state that.

> (A3) Where conflict exists the dynamic loader prints a warning for an env var
>      that is ignored e.g. clear and consistent visibility for users.
>
> (A4) Give preference to any executable-encoded choices over environment variables.

Agreed.

> Picking a winner:
> 
> Notes:
> - When "print a warning" is written this can mean that we only print something
>   if LD_DEBUG=all is set or something that matches the warnings we would like
>   to print.

Agreed, with emphasis that we should not print anything from the dynamic
linker unless absolutely necessary.

To expand on LD_DEBUG, it should be the lowest priority.  That is,
LD_DEBUG should give you all kinds of diagnostic messages if you request
them, but it will not get in the way of any other feature enabled either
via the environment or through build flags.  It must not change program
(or program loading) behaviour.

For DF_BIND_NOW vs DT_AUDIT, the following rules seem obvious assuming
that we generally want auditing to be able to override immediate binding
and they more or less align with yours:

1. The static linker should not allow DT_AUDIT and DF_BIND_NOW on the
same object.  Print an error and force the user to choose one or the other.

2. The built-in option wins over envvars

3. If both LD_BIND_NOW and LD_AUDIT are provided, choose auditing.
Print a warning if LD_DEBUG is also set

I'm not clear however whether you intend to have DT_AUDIT impact the
entire program or just the DSO in question.  That is, would one DSO
having DT_AUDIT result in auditing of all linker activities for all DSOs
or for just the DSO that is linked with DT_AUDIT.  Also what about cases
where different DSOs are linked with different DT_AUDIT lists?  Finally,
what do their linker namespaces look like, are they distinct from each
other or do they get merged into a single namespace, distinct from the
default namespace?

Some of those answers may affect the extent to which we can or cannot do
lazy binding alongside DT_AUDIT.

Siddhesh