Leaks `LD_LIBRARY_PATH` into application - including zed terminals

[jmaargh]

This flatpak leaks its value of LD_LIBRARY_PATH (somewhere in /var/lib/flatpak/app/dev.zed.Zed on my system) into the application and, importantly, therefore into terminal instances within the application.

This can cause weird and confusing changed behaviour between developing within the zed terminal versus any other terminal emulator because different libraries will be loaded in unexpected ways. It is worth noting that the flatpak of vscodium does not leak LD_LIBRARY_PATH

Comparing env | grep -e 'zed' to env | grep -e 'codium' from their respective terminals reveals leaked environment from the flatpaks. Zed actually appears to do better for the most part - the only problematic one I can see leaked is LD_LIBRARY_PATH -- this flatpak otherwise seems to have done a good job of namespacing its environment variables to not interact with user scripts/bashrc/etc.

[Fringale]

On my system (Aeon Desktop / openSUSE Tumbleweed derivative), after upgrading to Zed 0.230.0, this LD_LIBRARY_PATH variable leak now appears to break some commands started from Zed.

More precisely, this causes commands launched from either a task or the integrated terminal (e.g. flatpak run …) to either throw dynamic linking errors or fail outright due to those errors, suggesting a mismatch between host libraries and those injected via LD_LIBRARY_PATH.

---

Steps to reproduce

From the integrated terminal, launch:

• First flatpak --help
• Then grep --help

Expected behavior

Commands run normally: flatpak and grep helps are both shown in the terminal.

Actual behavior

The flatpak --help command fails with the errors below:

flatpak: /home/<user>/.local/share/flatpak/app/dev.zed.Zed/x86_64/stable/e88f8d8e3dcbbb9a23501fdeb645d10ccf2e9da23ae10d02c47b88bb912fa2a2/files/lib/libselinux.so.1: no version information available (required by /lib64/libostree-1.so.1)
flatpak: /home/<user>/.local/share/flatpak/app/dev.zed.Zed/x86_64/stable/e88f8d8e3dcbbb9a23501fdeb645d10ccf2e9da23ae10d02c47b88bb912fa2a2/files/lib/libselinux.so.1: no version information available (required by /lib64/libkrb5support.so.0)
flatpak: symbol lookup error: /lib64/libdconf.so.1: undefined symbol: g_assertion_message_cmpint

The grep --help command succeeds but throws the following error:

grep: /home/<user>/.local/share/flatpak/app/dev.zed.Zed/x86_64/stable/e88f8d8e3dcbbb9a23501fdeb645d10ccf2e9da23ae10d02c47b88bb912fa2a2/files/lib/libpcre2-8.so.0: no version information available (required by grep)

Workaround

Unsetting LD_LIBRARY_PATH fixes the issue:

• env -u LD_LIBRARY_PATH flatpak --help
• env -u LD_LIBRARY_PATH grep --help

---

Note: I verified via Warehouse that this issue is not present in previous Zed versions on my system, it only appears starting with 0.230.0.

[stephanlachnit]

This also causes #224 btw - unsetting LD_LIBRARY_PATH fixes podman within Zed.

[Fringale]

@tomaswarynyca I'm not sure this issue should have been closed as a consequence of Zed no longer escaping the sandbox by default: Zed flatpak leaking LD_LIBRARY_PATH and the problems this behavior is causing are still there unfortunately, just not present out of the box anymore.

[cxrvh]

I believe it's actually an upstream & not a flatpak issue - though it is flatpak specific. Flatpak unsets LD_LIBRARY_PATH.

When escaping the sandbox, Zed caches its library path in order to launch outside the sandbox with LD_LIBRARY_PATH set (the comment seems imprecise - it should say if launched/spawned from the flatpak sandbox. When running under flatpak the library path is set by the runtime).

[stephanlachnit]

You can fix this by unsetting LD_LIBRARY_PATH in your terminal configuration:

  "terminal": {
    "env": {
      "LD_LIBRARY_PATH": "",
    }
  }