Is there a recommended way for testing
if the configuration is effective and the
lookup is indeed disabled?
The log file for the container contains an entry for JVM arguments on startup, which
should include
Dlog4j2.formatMsgNoLookups=true if fixed. This can be accessed by 'docker logs
xxx' on the ElasticSearch container.
It'd be nice to have a test case, though - I tried pasting a test string from the
web-based tool mentioned into the MediaWiki search box, but I am not sure if this is a
suitable test.
FWIW, Docker doesn't make it easy to modify an existing container's environment
for quick fixes without making a whole new one. Of course the "right" way is to
recompose it. However, if for any reason you don't have files to hand, and don't
want to mess around with an overlay like
https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay (which I'm not sure
works; it depends on the version of log4j used), or don't want to switch containers,
it seems possible to modify the environment for existing ones directly.
I found the container ID for elasticsearch with 'docker ps', stopped the docker
daemon with 'systemctl stop docker' (stopping the specific container is not
enough), edited config.v2.json in /var/lib/docker/containers/xxx... such that the
ES_JAVA_OPTS had the additional option and then 'systemctl start docker' - judging
by tail -n 50 of the log file in that directory, the environment variable was correctly
set. Take that with a huge pinch of salt, though; I'm not a docker expert. 😅
--
Laurence 'GreenReaper' Parry