> Then there is the thing that LD_LIBRARY_PATH and similar are MAJOR security holes, and most systems would be best of to use hardening techniques to disable it (not to be confused with `/etc/ld.so.conf`).
I do not consider LD_LIBRARY_PATH or LD_PRELOAD more a security hole than PATH itself.
There is two scenarios:
- you control exactly how your program launcher (environment variables, absolute path) andit's a non issue
- you do not control the environment properly and the everything is a security hole.
That's said: DT_RUNPATH and RPATH are however beautiful security holes.
They allow to hardcode loading path in the binary itself even with a controlled environment.
And many build tools let garbage inside these path unfortunately (e.g /tmp/my_build_dir )
From a desktop point of view Linux needs some major improvement about how it handles applications.
It also has all tools to do so, but it would brake a lot of existing applications.
In the past I though Flatpack and Snap would steps in the right direction. But now I'm not so sure about that anymore (snap made some steps in the right direction but also many in wrong directions, flatpack seems to not care about anything but making things run easier, in both cases moving from a kinda curated repo to a not-really curated one turned out horrible).
For a server point of view things matter much less, especially wrt. modern setups (container, vm in cloud, cloud provider running customized and hardened Linux container/vm hosts, etc).
And in the end most companies paying people to work on Linux are primary interested in server-ish setups, and only secondarily in desktop setups (for the people developing the server software). Some exception would be Valve, I guess, for which Linux is an escape hatch in case bade lock-in patterns from phone app-stores take hold on windows.
I do not consider LD_LIBRARY_PATH or LD_PRELOAD more a security hole than PATH itself.
There is two scenarios:
- you control exactly how your program launcher (environment variables, absolute path) andit's a non issue
- you do not control the environment properly and the everything is a security hole.
That's said: DT_RUNPATH and RPATH are however beautiful security holes. They allow to hardcode loading path in the binary itself even with a controlled environment.
And many build tools let garbage inside these path unfortunately (e.g /tmp/my_build_dir )