Needing a LD_PRELOAD on a system where LD_PRELOAD is blocked.

Sure it still requires you to have rights to create+run a executable.

But it's a much better model then LD_PRELOAD as it can only be used on executable you can write to, which normally means you your user/group but not other user/group owned executables. Which is especially relevant with suid/sgid.

You can also use this, to patch a library which is compiled in a way where LD_PRELOAD doesn't work. Like suid binaries. Through you have to potentially make a copy and set the suid bit again.

Yeah, I've been using it to set rpath on some files that needed to be packaged in a particular way...

Being able to add or update the rpath on apps and shared objects is pretty handy, particularly when the target would be annoying or problematic to rebuild.

To add, there's chrpath(1), but that can't grow the field in the ELF file, so you can only change the rpath to something shorter than it is now, and usually it's empty.

We use this at my workplace to add $ORIGIN-relative rpaths to third-party dependencies of internal code, since we want to distribute/version those along with the code, not with the OS, and we also don't want to distribute them in the medium of OS packages (so you don't have to be root, so we don't risk messing up the base OS, etc.). In many senses that's just a "non-FHS distro," but it's arguably not a distro at all.

Even for easy-to-compile third-party code, squeezing -Wl,-rpath into all the right places is more of a pain than you'd hope, so we just run patchelf on everything in the third-party directory at the end of the build, regardless of whether the "build" is an actual build or just an untar of proprietary software.

I've used it to edit a binary's rpath as part of relocating binaries that really want to be installed at a certain path.

You can do this yourself with e.g. hexedit if your new path is shorter but if it's longer you need something smarter, like patchelf.

You don't even need to patch it to include a certain path, you can use (and I have used) it to include $ORIGIN or $ORIGIN/../lib in programs' RPATHs.

Be careful about when this is and isn't okay though. When used wrong this can be a security risk, such as when your browser auto-downloads files to a Downloads folder, and the program you are patching is also in there.

Some of the things it does are extremely handy for simple privilege escalation attacks.

It’s an easy way to modify the binary to load extra code, which can alter how it behaves.

Sure, but only if you have write access to the binary. If you have that you can already replace it with anything you like, so I am not seeing the privilege escalation there.

Consider the context in which PT_INTERP is loaded and executed.

There should be no situation where a malformed or unexpected PT_INTERP leads to privilege escalation. If you believe you have found such a situation, please report it.

Lots of Python packages containing native code are optionally distributed with pre-compiled libraries that have been modified with patchelf. I believe both auditwheel (https://pypi.org/project/auditwheel/) and conda-build do this.

Yes. Auditwheel inspects the native python parts and shoves any external .so dependencies into the wheel, making it hermetic.

Sounds like something that would make binary patching easier. Lack of simple binary patching is one of the key bits missing that would make switching to static binaries more viable. Currently one of the big upsides to dynamic libraries is the bandwidth they save in distribution where binary patches would go a long way to addressing this.