ValveSoftware
[pressure vessel] missing host environment variables to filter out
This is related to the usage of the pressure vessel in dota2:
Since the pressure vessel is providing its own libs with their own data files located in the container, some environment variables from the host should be filtered out:
libX11/libxkbcommon-x11:XLOCALEDIR libasound(alsa-lib):ALSA_CONFIG_DIR libthai(text shapping):LIBTHAI_DICTDIR
It seems there are some more for libxkbcommon(-x11):XKB_CONFIG_ROOT (dunno if it is for wayland and x11 though).
Ofc, many of those data files could be customized using user specific or system specific files (~/.asoundrc /etc/xkb ...), namely if upstream changes the format or some significant content, that would make the container data files not compatible anymore.
I did not inventory all the software packages from the container, but that should be done to avoid wrong path definitions from the host environment variables propagating into the container.
libasound(alsa-lib):ALSA_CONFIG_DIR libthai(text shapping):LIBTHAI_DICTDIR
As you say, we expect to be picking these up from the container runtime and not from the host system.
The vast majority of distributions install these libraries in such a way that their compiled-in default paths will find their data files, and therefore the environment variables aren't set in practice. I would recommend that approach to OS builders rather than relying on an increasingly large set of environment variables inheriting down through the whole process hierarchy: that way, the environment variables only need to be set if you're doing something special (like debugging a specific issue using a temporary locally-modified library).
Is your distribution (what distribution is that? does it have a name?) installing its normal production versions of these libraries into a location outside the usual /usr or /usr/local?
libX11/libxkbcommon-x11:XLOCALEDIR
This one is not so simple. We'll often pick up the host's copy of libX11 as a dependency of the graphics drivers, which could mean that in principle we should be using the host's XLOCALEDIR too (possibly with adjustments for /usr → /run/host/usr if necessary, since the real system's /usr turns up at /run/host/usr inside the container). Ideally we'd use the host's XLOCALEDIR if we're using the host's libX11, but unset it if we're using the container's libX11.
Because of the way library dependency relationships work, if your graphics drivers depend on libX11 (which in practice they will), we must use either the host's or the container's libX11, whichever one is newer - we don't get a choice about this.
As with the other libraries, the vast majority of distributions install libX11 in such a way that its defaults will find locale files, and therefore XLOCALEDIR is not set in practice. Is your distribution installing it into a location outside the usual /usr and /usr/local?
XKB_CONFIG_ROOT
I'd have to check the dependency graph to have a better idea of whether we're likely to pick this up as a dependency of the graphics driver stack (in which case it's like libX11) or not (in which case it's like libasound). Either way, it would get the same handling as one of the libraries described above.
Basically, if the container uses its own version of a lib, it will have to filter out such type of environment variables in order to use its own location, and indeed, some are "shared" in the x11 realm.
But it means components in the container should be audited regarding this issue.
The "heavy" steam runtime the steamwebhelper is using should set those environment variables to point on the locations of its own data files.