Closed tomeichlersmith closed 3 months ago
This issue is not applicable to docker runners where the container-internal environment variables override the variables set on the command line.
(seen by comparing output of denv printenv
between a sharing-all denv config env all on
and a sharing-none denv config env all off
)
I was mistaken, we (and distrobox) do filter out PATH
from the environment variables that are copied, but other *PATH
variables (e.g. LD_LIBRARY_PATH
or PYTHONPATH
) are not filtered. Going to try to update to prevent these paths from being set from outside the container by simply updating the bad-var-name regex.
https://github.com/tomeichlersmith/denv/blob/b4b8556fdd8b23b7a2c0f2537e8deed16d6bbf6a/denv#L384
Noticed this while trying to use combine which needs the container-defined LD_LIBRARY_PATH in order to load the shared libraries when running.
Alternative Currently, you can avoid this manually by running in a more environment-restricted mode.
Solution I think
denv
should make the opinionated choice to not share*PATH
variables by default. This is the opposite choice made compared to distrobox; however, I think it makes sense in order to isolate the programs in the denv from the programs in the host. I still think there should be some path (lol) for sharing specific*PATH
variables if the user desires, i.e. allow them viadenv config env copy
but exclude them fromdenv config env copy all
.Edit: To be more clear, I think distrobox combines both the host and the internal
*PATH
variables so that both are available within the containerized environment. I'll need to look into that to see if its possible but I don't think it is since the limiting factor seems to be how apptainer defines the envrionment variables (i.e. with somesh
init scripts that check if they are already defined).