Toward safer GNU C Library tunable handling

The main takeaway for me is that a lot of tunable env vars like this may not be well documented on systems in a way that the millions and millions of people who admin and develop on Linux are generally aware they even exist, let alone could list the various settings and describe what they do. glibc is probably not the only library which has optional behavior which can be set by environment variables that could break a program, which the developers and users aren't taking sufficient precaution against because they aren't aware of the risk.

Problem 1: The method of applying tunables via environment is intrusive on a systems design/management level.
Being able to tune via environment is convenient, but - to state the obvious - it actually requires modifying the environment. Therefore, to be able to tune/trace every process, every potential process start has to be wrapped individually. A central policy mechanism could relieve system engineering from re-implementing this for every process that can be run in a system and that should be tuned/traced, making the tunables accessible where they right now are not (think containerized workloads etc.)

Problem 2: Being able to apply tunables via every process's environment makes a system's behavior less clear.
Given the current tuning configuration mechanism, it is a non-trivial task to state how a system currently actually behaves. Many corner cases have to be considered. Just some examples: Can a process apply tunables to itself by modifying its own environment? Is it safe to state that, if a process's environment contains a tunable setting X, then X is actually effective? Is it safe to state that X applies to all threads of X or only future threads? Also consider the special rules that apply to SUID/SGID binaries. Etc, etc. Much like discretionary access control, it's another semantical nightmare in audit situations.

Problem 3: The current design of the tunables configuration interface offers a questionable mixup of debugging and performance settings.
The current set of tunables mixes settings for tuning (e.g. hugeTLB) with settings for tracing (e.g. malloc check). A central policy syntax maybe could allow for a splitting of these substantially different activities into separate mechanisms, or maybe just a "sounder" design in general.

I am aware that my ramblings do not include even a hint of an idea of how to actually accomplish such improvements, because frankly i have none!

It's hard to think of a valid use of environment passed in. For instance even dynamic linking with a local directory, you would optionally at build time insert a fixed directory to the default runtime .so search path. You could not rely on users not breaking environment.

This sounds like GNU lost the plot on this, when ld.so has an altered [ui]d it is simply asking for trouble to worry about a user's POSIXLY_CORRECT setting or other options that might introduce unanticipated behaviour.

Such programs are supposed to be small, carefully written and sanitise all input including the environment. Glibc tunables broke that contract.

Things worked before these GNU tunables, it's unclear why ld.so is EVEN looking at them when exec changes the effective [ug]id.

It's not environment that's broken it's a badly thought out feature created by glibc.