fix(elasticsearch): stay root at runtime, fix upgrade permission failure

Reported: on upgrade from an existing 7.17.9 install, the add-on failed
to start with "mv: cannot move '/data/config' to
'/data/config.bak-7.17.9': Permission denied".

Root cause: a previous fix in this same release restored `USER 1000:0`
at the end of the Dockerfile to match the upstream base image's own
final USER directive. But the upstream 8.19 entrypoint no longer drops
privileges itself (confirmed: it execs elasticsearch directly, no
gosu/chroot dance), and existing installs have /data owned by root
(7.17.9's default image variant runs fully as root). A non-root
container can never chown or move that data.

Revert to root at runtime, matching how this add-on always ran and
matching its own AppArmor profile (chown, setuid, setgid, sys_chroot,
mount capabilities — all meaningless for a non-root process anyway).
Root stays required for the build-time entrypoint patch too, unchanged
from the prior fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

elasticsearch/CHANGELOG.md

@@ -8,8 +8,9 @@
 - Removed the `ingest-attachment` plugin install: it is a bundled module since Elasticsearch 8.0.
 - Startup persistence logic rewritten as a proper init script (`/usr/local/bin/addon-init.sh`) instead of line-number-based entrypoint patching.
 - Added `updater.json` so upstream 8.19.x releases are tracked automatically (pinned to the 8.19 line: 9.x cannot read indices created in 7.x).
-- The upstream 8.x image ends the build as a non-root user with a read-only entrypoint; the Dockerfile now switches to root for the build steps that patch/install into it and restores the Elasticsearch user before runtime.
+- The upstream 8.x image ends the build as a non-root user with a read-only entrypoint; the Dockerfile now switches to root for the build steps that patch/install into it. The image stays root at runtime too (unchanged from 7.17.9): the upstream entrypoint no longer drops privileges itself, and `addon-init.sh` needs to chown/move pre-existing `/data` content that may be owned by root from earlier installs.
 - `env_vars` names starting with a digit are now rejected before export instead of crashing the entrypoint.
+- Fixed a startup failure (`mv: cannot move '/data/config' ... Permission denied`) on upgrade from an existing 7.17.9 install, caused by an earlier fix in this same release that switched the runtime user to non-root before this fix was in place.
 
 ## 8.14.3-3 (2026-06-19)
 - Fix startup failing with `chroot: cannot change root directory` by allowing `capability sys_chroot` in the AppArmor profile (#2709)

elasticsearch/Dockerfile

@@ -141,5 +141,9 @@ HEALTHCHECK \
     --timeout=25s \
     CMD curl -A "HealthCheck: Docker/1.0" -s -f "http://127.0.0.1:${HEALTH_PORT}${HEALTH_URL}" &>/dev/null || exit 1
 
-# Restore the Elasticsearch user for runtime, matching the base image
-USER 1000:0
+# Stay root at runtime: addon-init.sh must chown/mv pre-existing /data
+# content that may be owned by root from earlier installs, and the upstream
+# entrypoint no longer drops privileges itself, so a non-root container
+# can't touch that data at all. This matches the addon's own AppArmor
+# profile (chown, setuid, setgid, sys_chroot, mount capabilities), which
+# assumes a root process.

elasticsearch/rootfs/usr/local/bin/addon-init.sh

@@ -1,8 +1,9 @@
 #!/bin/bash
 # shellcheck shell=bash
 # Sourced by /usr/local/bin/docker-entrypoint.sh (right after "set -e"),
-# before Elasticsearch starts. Runs as root when the Supervisor starts the
-# container; the official entrypoint then drops privileges itself.
+# before Elasticsearch starts. Runs as root (the image stays root at
+# runtime - see Dockerfile); the official entrypoint does not drop
+# privileges itself, and Elasticsearch ends up running as root too.
 #
 # Responsibilities:
 #   1. Export user env_vars from /data/options.json