[Question]: What is the recommend method to have LD_PRELOAD honored by flatpak applications?

[qoijjj]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

There is a partially related comment I made here: #5575 (comment)

But that doesn't fully capture the question. The question is, what is the method recommended by flatpak officially to have LD_PRELOAD honored by flatpak applications?

[adrelanos]

Specifically this would be useful to LD_PRELOAD hardened_malloc, a security-focused general purpose memory allocator.

[adrelanos]

related:
Flatpak Request for hardened_malloc

[smcv]

The recommended method is "don't". Any native code that exists on the host system OS distribution can legitimately have dependencies on libraries in the host system OS distribution that do not exist, or exist but are too old or incompatible, inside the Flatpak runtime.

If you want to inject arbitrary code into programs running inside the Flatpak sandbox (whether that's a hardened, instrumented or otherwise modified malloc(), some other LD_PRELOAD module like faketime, a Vulkan layer like MangoHUD, or any other similar thing) then it needs to be compiled against the Flatpak runtime's dependency libraries and shipped as a Flatpak extension. An extension is a special runtime that acts like a plugin for other apps and runtimes.

[qoijjj]

@smcv Thanks again. I'll be pursuing the extension route. To be clear though, in this specific case the hardened_malloc lib doesn't depend on anything else so for this specific use case it works fine. But I understand why this may well not be the case for other libraries.

[smcv]

in this specific case the hardened_malloc lib doesn't depend on anything else

A malloc implementation presumably needs some way to ask the kernel for more memory, which I imagine is using system calls like mmap() or possibly sbrk(). Unless you are implementing those system calls yourself, on a per-architecture basis, in assembler, this library is going to have a dependency on glibc ABI.

It might only be using ABI entry points that have existed since time immemorial (like malloc() or syscall()) and therefore are interoperable between the host OS's glibc and the Flatpak runtime's glibc in practice, but it's vanishingly unlikely to have no dependencies at all.

[hfiguiere]

question answered