Problem: Extremely surprising that DevContainers mutates system-wide /etc/environment at all.
This is a pretty insane architectural choice for a few reasons:
- fails rule of lease surprises
- is a breaking-change compared to other container runners, doesn't match deployment of a target container
- major security concern for per-user secrets, or build-time only secrets, getting injected into the system environment where every user (e.g. daemon web applications, databases, etc.) now potentially has these secrets in their environment
Reproduce this issue, create a Dockerfile:
FROM ubuntu:24.04
ENV DEBIAN_FRONTEND=noninteractive
# Layer 1: Locale + Timezone
RUN apt-get update && apt-get install -y --no-install-recommends \
locales tzdata \
&& sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen \
&& locale-gen \
&& ln -fs /usr/share/zoneinfo/America/Los_Angeles /etc/localtime \
&& dpkg-reconfigure -f noninteractive tzdata \
&& rm -rf /var/lib/apt/lists/*
ENV LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 TZ=America/Los_Angeles
# Switch to picard user for all per-user tool installs
USER picard
WORKDIR /home/picard
# Layer: Rust (stable via rustup)
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- \
-y --default-toolchain stable --profile default
ENV PATH="/home/picard/.cargo/bin:$PATH"
Just opening a container using VsCode will edit the /etc/environment:
|
async function patchEtcEnvironment(params: ResolverParameters, containerProperties: ContainerProperties) { |
|
const markerFile = path.posix.join(getSystemVarFolder(params), `.patchEtcEnvironmentMarker`); |
|
if (params.allowSystemConfigChange && containerProperties.launchRootShellServer && !(await isFile(containerProperties.shellServer, markerFile))) { |
|
const rootShellServer = await containerProperties.launchRootShellServer(); |
|
if (await createFile(rootShellServer, markerFile)) { |
|
await rootShellServer.exec(`cat >> /etc/environment <<'etcEnvironmentEOF' |
|
${Object.keys(containerProperties.env).map(k => `\n${k}="${containerProperties.env[k]}"`).join('')} |
|
etcEnvironmentEOF |
|
`); |
|
} |
|
} |
|
} |
# Open a shell inside the container
docker compose exec claude-dev zsh
From the container:
cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
ANTHROPIC_API_KEY="sk-ant-your-key-here"
OPENAI_API_KEY="sk-your-key-here"
GEMINI_API_KEY="your-key-here"
PATH="/home/picard/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
DEBIAN_FRONTEND="noninteractive"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
TZ="America/Los_Angeles"
In this repro, it means that every user's Rust bin will be served from the picard user's home directory. That's just not how this should work.
I don't believe this is the intention for the ENV directive of a Dockerfile!
https://docs.docker.com/reference/dockerfile/#env
When you run docker exec, the container runtime reads the same image config and passes the ENV vars via execve to the new process, regardless of which user it runs as (--user). So every docker exec session gets them. But this is very different than injecting it into /etc/environment where the change is persisted for any user logging into the container (e.g. ssh) and not limited to docker exec.
Problem: Extremely surprising that DevContainers mutates system-wide
/etc/environmentat all.This is a pretty insane architectural choice for a few reasons:
Reproduce this issue, create a Dockerfile:
Just opening a container using VsCode will edit the
/etc/environment:cli/src/spec-common/injectHeadless.ts
Lines 750 to 761 in 65f98a5
From the container:
In this repro, it means that every user's Rust bin will be served from the
picarduser's home directory. That's just not how this should work.I don't believe this is the intention for the
ENVdirective of a Dockerfile!https://docs.docker.com/reference/dockerfile/#env
When you run
docker exec, the container runtime reads the same image config and passes theENVvars viaexecveto the new process, regardless of which user it runs as (--user). So every docker exec session gets them. But this is very different than injecting it into/etc/environmentwhere the change is persisted for any user logging into the container (e.g.ssh) and not limited todocker exec.