This post is great. Kudos to the author for writing this up; it helped me learn about some things I knew the dynamic linker had some way of doing but I didn't have name for. One question:
> In contrast, on Darwin, the (somewhat) complete path to the library installation, known as that library's install name, is used. This has presumably been done that way in order to prevent dylib hijacking, an attack where a malicious dylib gets placed in the library search path before the real one, which allows the malicious dylib to execute arbitrary code on the behalf of the executable that got tricked into loading it.
Couldn't you just get around this by running the application in a fake root?
I don't think install_name has for purpose to prevent dylib hijacking. In fact there were DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH, and other stuff that used to trivially† go around that (now disabled — IIRC — when SIP is active). The purpose of install_name and @executable_path is, to me, to leverage the concept of a bundle (may it be a .app or a .framework) to solve dependency hell issues and have self-contained, relocatable, forward- and backward-compatible software.
I never could figure out how to work around the multilevel namespaces to implement something like LD_PREDLOAD without recompiling with namespaces turned off. Wish I had this article then.
> In contrast, on Darwin, the (somewhat) complete path to the library installation, known as that library's install name, is used. This has presumably been done that way in order to prevent dylib hijacking, an attack where a malicious dylib gets placed in the library search path before the real one, which allows the malicious dylib to execute arbitrary code on the behalf of the executable that got tricked into loading it.
Couldn't you just get around this by running the application in a fake root?