Entrypoint needs to chown data directory

[atombender]

The Dockerfile chowns various directories, including the data directory, but this is a bit nonsensical since nobody runs the image in production with the default data directory; the chown doesn't work with a volume mapping. Specifically, under Kubernetes, with a persistent volume claim (e.g. via a statefulset), the volume mounted is owned by root.

The idiomatic way of handling this is to let the entrypoint run as root, ensure the directory permissions, then drop privileges:

mkdir -p $data_dir
chown elasticsearch $data_dir
chmod 0755 $data_dir
exec su-exec elasticsearch bin/elasticsearch  # or gosu or whatever

The only way to do this from Kubernetes without modifying the official image is with an init container, which should be unnecessary, and is obviously potentially brittle since it'd need to chown using the numerical UID that's hard-coded in this Dockerfile.

[dliappis]

This has been discussed a few times e.g. #32 (comment)) and #70 (comment).

You will find the reasoning behind the current behavior in those comments, one of which is that mutating the permissions and ownership of host dirs from inside a container is an unpredictable and non-secure practice for a generic image; far from the predictable and isolated promise of containers.

I understand that in k8s there is no support for named volumes yet, so things are a bit more limited. There are also some discussions in k8s: kubernetes/kubernetes#2630 and a PR here for specifying a supplemental group.

I will leave this open, in light of the k8s case and think/discuss about a viable approach for k8s.

[dliappis]

Closed by #125, support will come starting with version 6.0