Pick up LD_PRELOAD when set by the user

[guihkx]

This allows users to set an override for LD_PRELOAD, e.g.:

flatpak override --user "--env=LD_PRELOAD=$HOME/.var/app/com.spotify.Client/useful_lib.so" com.spotify.Client

[flathubbot]

Started test build 112207

[flathubbot]

Build 112207 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/95022/com.spotify.Client.flatpakref

[Erick555]

Did you tested it?

Variables in --env aren't expanded so $HOME will be literal $HOME nonsense path instead of actual homedir. It's also probable that inheriting arbitrary LD_PRELOAD from host may break something.

[TingPing]

It would never automatically inherit from host so that isn’t a problem.

I do wonder what the use case is though.

[guihkx]

Did you tested it?

Yup, I did. It works.

Variables in --env aren't expanded so $HOME will be literal

In the example I gave, the only scenario where $HOME wouldn't get expanded, is if we wrapped it around single quotes ('), as far as I know. I've tested this with Bash and Fish shell.

I do wonder what the use case is though.

Adblockers, mostly. Though I'm not exactly sure if it'd be appropriate for me to link them here?

[Erick555]

It would never automatically inherit from host so that isn’t a problem.

What do you mean? Flatpak does inherit LD_PRELOAD from host, I even linked issue about it.

[guihkx]

Flatpak does inherit LD_PRELOAD from host

It does, indeed. Though I question if it's a behavior we should care about.

In my opinion, if users have LD_PRELOAD set globally on their machine, and that somehow causes some Flatpak app to break, it's a problem they introduced.

On my tests, Spotify didn't break even when I tried to preload an invalid lib, e.g.:

flatpak run --env=LD_PRELOAD=/foo/libcef.so com.spotify.Client

[TingPing]

I even linked issue about it.

Oh wow. Sorry you're right. It just sounded so crazy I made an assumption.

[TingPing]

https://github.com/flatpak/flatpak/pull/5765