[Bug]: dotted environment variables are lost

[yosifkit]

Please add the exact image (with tag) that you are using

eclipse-temurin:11-jdk-focal

Please add the version of Docker you are running

Docker version 24.0.5, build ced0996

What happened?

Environment variables are lost and unavailable to the java process.

From the related issue in the Tomcat image:

we have noticed that since about 2 days our java servlet cannot read environment variables which have a "." in the name.

Short example: System.getenv("variable.with.a.dot") returns null

where System.getenv("variablewithoutdot") returns the correct variable value.

We set the environment variables via the docker compose .env file.

The timing corresponds to the dependent image rebuilds caused by https://github.com/docker-library/official-images/pull/15162. We haven't made changes to the Tomcat Dockerfiles since July 10.

This has the same root cause as we had in https://github.com/docker-library/tomcat/issues/77. sh removes env vars it doesn't support (ones with periods), but bash does not. The new entrypoint from https://github.com/adoptium/containers/pull/392 is sh on Ubuntu and Alpine images and so loses variables. Please change all the entrypoint scripts to use bash

Relevant log output

No response

[rassie]

Thanks for the report. The change is being backed out right now (https://github.com/docker-library/official-images/pull/15192) until we solve this. We'll need to add bash to Alpine images first, but I suppose it won't be long until this is solved.

[gdams]

@yosifkit I'm looking back at this error again to see if we can remove the bash dependency on Alpine. One question I had was how does Docker handle dotted environment variables in the base image when there's no bash shell?

docker run --rm -e "variable.with.a.dot=value" alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=a049f2328bb6
variable.with.a.dot=value
HOME=/root

Is this some special docker logic that's happening behind the scenes? And can we benefit from this same logic in our entrypoint.sh script?

[yosifkit]

Is this some special docker logic that's happening behind the scenes? And can we benefit from this same logic in our entrypoint.sh script?

Docker isn't doing anything extra for environment variables. It just sets them on the process that it starts (probably similar to Env on an exec.Cmd: https://pkg.go.dev/os/exec#Cmd). The problem arises if there is a process between Docker and the java binary, like sh, that might scrub the variables that are set before running exec java -jar ... or similar.

Though, now that I try, it seems that Alpine's sh doesn't scrub them, but Ubuntu's sh (i.e., dash) does. I was fairly certain it behaved the same way. 🤷😕 It must have changed since https://github.com/docker-library/openjdk/issues/135 and https://gitlab.alpinelinux.org/alpine/aports/-/issues/7344.

$ docker run --rm -e "variable.with.a.dot=value" eclipse-temurin:17-jdk-alpine sh -c 'exec env' | grep dot
variable.with.a.dot=value
$ docker run --rm -e "variable.with.a.dot=value" eclipse-temurin:17-jdk-jammy sh -c 'exec env' | grep dot
$ # no output ^

---

Looks like it was changes in busybox itself, so for a few versions of Alpine, it didn't work. I don't know if it'll break again in a future busybox update in Alpine.

$ docker run --rm -it -e test.var=alpine busybox:1.25.0 /bin/sh -c 'env' | grep 'test.var'
test.var=alpine
$ docker run --rm -it -e test.var=alpine busybox:1.26.0 /bin/sh -c 'env' | grep 'test.var'
$ docker run --rm -it -e test.var=alpine busybox:1.27.0 /bin/sh -c 'env' | grep 'test.var'
$ docker run --rm -it -e test.var=alpine busybox:1.28.0 /bin/sh -c 'env' | grep 'test.var'
test.var=alpine