[Pkg-utopia-maintainers] Bug#980323: flatpak: LD_LIBRARY_PATH is not set under flatpak-builder

[Simon McVittie]

Control: forwarded -1 https://github.com/flatpak/flatpak/issues/4080
Control: found -1 1.8.5-1
Control: found -1 1.10.0-1

On Sun, 17 Jan 2021 at 21:20:38 +0200, Joonas Sarajärvi wrote:
> With flatpak 1.2.5-0+deb10u2, LD_LIBRARY_PATH is not set when invoked
> over flatpak-builder. This became apparent when I was reviewing [1],
> where a contributor intends to add the Jansson library to be shipped
> alongside GNU Emacs in the /app/lib directory. Usually the build
> environment provided by flatpak-builder would have this directory
> referred to by LD_LIBRARY_PATH. With this latest security update, the
> environment variable is entirely absent.

Good catch, this is a regression in the security update. It primarily
affects Debian 10 (with or without Flatpak from -backports), because
Debian testing/unstable has a non-setuid version of /usr/bin/bwrap.

Here is a more minimal reproducer:

$ flatpak install org.freedesktop.Sdk//20.08
$ flatpak install org.freedesktop.Platform//20.08
$ flatpak build-init _flatpak-build com.example.App org.freedesktop.Sdk org.freedesktop.Platform 20.08
$ flatpak build _flatpak-build -- sh -c 'echo "$LD_LIBRARY_PATH"'

Expected result:
/app/lib:/usr/lib/x86_64-linux-gnu/GL/default/lib:/usr/lib/x86_64-linux-gnu/openh264/extra

Actual result: no output.

Workaround: on machines that will build Flatpak apps/extensions, make
/usr/bin/bwrap non-setuid by using dpkg-statoverride, then set the sysctl
kernel.unprivileged_userns_clone=1 to allow it to create new namespaces
anyway. This is how it's going to work in Debian 11; it has a greater
security risk via kernel attack surface being exposed, but less security
risk via bwrap being setuid, so it's a security trade-off.

I've contacted upstream to work out what is the best way to resolve this
regression. There are a couple of options that should both work, but I'm
not sure which one is going to be preferred.

> I would still expect that
> flatpak 1.2.5-0+deb10u2 can run the same flatpaks when consumed
> prebuilt from e.g. flathub.

Yes, I think so. One thing that might have regressed for the same reason
as `flatpak build` are the hooks to "apply extra data", used for things
like unpacking archives containing proprietary apps or NVIDIA graphics
drivers: that's the other code path that previously got the runtime's
LD_LIBRARY_PATH and now doesn't.

> The mechanism for linker paths is not
> based on LD_LIBRARY_PATH when flatpak is simply run, as opposed to
> building.

Yes and no. It actually *is* based on LD_LIBRARY_PATH, sort of, but
then the LD_LIBRARY_PATH gets transformed into ld.so.conf.d fragments
and Flatpak builds a new ld.so.cache. However, even if the ld.so.cache
mechanism is not being used, this code path doesn't suffer from the
regression, because it's the one I was looking at when I wrote the
security fix.

    smcv