Not exporting `LD_LIBRARY_PATH` in desktop helpers when using classic confinement

snapcraft
3

So the use case here is that a classic confined app wants to execute programs from outside the snap. In the VS Code case, this would include:

  1. executing the system compiler toolchain and other build tools
  2. executing/debugging the app the user is building

And you want to avoid passing on any environment that alters the execution of these subprocesses.

Just looking through what the desktop-launch script does, LD_LIBRARY_PATH is just the start. Among other things it will also:

  1. set GST_PLUGIN_PATH / GST_PLUGIN_SYSTEM_PATH to alter where GStreamer plugins are found
  2. set GI_TYPELIB_PATH to alter where gobject-introspection typelibs are found.
  3. set GIO_MODULE_DIR to change where GLib’s GIO modules are found.
  4. set GDK_PIXBUF_MODULEDIR to change where gdk-pixbuf modules are found.
  5. set GTK_PATH to change where GTK modules are found
  6. set GTK_IM_MODULE_DIR to change where input method modules are found
  7. set QT_PLUGIN_PATH to change where Qt plugins are found
  8. …

Any of these could also cause problems for subprocesses that use this functionality if there are incompatibilities between the system and snapped versions of these libraries. It’s also worth noting that some of these environment variables will be needed for correct functioning of the snapped version of the corresponding libraries, since the incompatibilities can go both ways.

You’re probably better off working out what aspects of the script you actually need in a classic environment rather than removing the the things that break one by one.

1 Like