[bitnami/elasticsearch] crash when running as root when TLS certificates are read-only

[ianroberts]

Name and Version

bitnami/elasticsearch:8.17.2-debian-12-r0

What architecture are you using?

amd64

What steps will reproduce the bug?

Run the container as root with a read-only volume mounted to /opt/bitnami/elasticsearch/config/certs.

(This bug was originally reported as bitnami/charts#25280 against the bitnami/elasticsearch Helm chart, which at the time mounted a Kubernetes secret at this path containing the TLS certificate and key files for Elasticsearch)

What is the expected behavior?

Container should start up correctly.

What do you see instead?

Container fails to start, with the error in this section of libelasticsearch.sh:

containers/bitnami/elasticsearch/8/debian-12/rootfs/opt/bitnami/scripts/libelasticsearch.sh

Lines 380 to 383 in 1e1e736

	for dir in "$DB_TMP_DIR" "$DB_LOGS_DIR" "$DB_PLUGINS_DIR" "$DB_BASE_DIR/modules" "$DB_CONF_DIR"; do
	ensure_dir_exists "$dir"
	am_i_root && chown -R "$DB_DAEMON_USER:$DB_DAEMON_GROUP" "$dir"
	done

When running as root the container attempts to chown all files under $DB_CONF_DIR (which is /opt/bitnami/elasticsearch/config), but this is not possible when the certs subdirectory is a read-only filesystem.

elasticsearch 14:33:47.48 INFO  ==> ** Starting Elasticsearch setup **
2024-04-19T22:33:47.494601985+08:00 elasticsearch 14:33:47.49 DEBUG ==> Ensuring expected directories/files exist...
chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/ca.crt': Read-only file system
2024-04-19T22:33:48.961388677+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/tls.key': Read-only file system
2024-04-19T22:33:48.961391451+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/tls.crt': Read-only file system
2024-04-19T22:33:48.961393308+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/..data': Read-only file system
2024-04-19T22:33:48.961395937+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/..2024_04_19_14_33_30.4069200578/tls.key': Read-only file system
2024-04-19T22:33:48.961398958+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/..2024_04_19_14_33_30.4069200578/tls.crt': Read-only file system
2024-04-19T22:33:48.961401321+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/..2024_04_19_14_33_30.4069200578/ca.crt': Read-only file system
2024-04-19T22:33:48.961404189+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs/..2024_04_19_14_33_30.4069200578': Read-only file system
2024-04-19T22:33:48.961411662+08:00 chown: changing ownership of '/opt/bitnami/elasticsearch/config/certs': Read-only file system

Additional information

A PR was accepted in the charts repository to "fix" the problem by copying the TLS certificates to a writeable volume instead of directly mounting the read-only one, but this has other undesirable effects where renewed certificates are no longer picked up and reloaded automatically. It would be better to back out that change to the chart and instead fix the problem at source in the container image.

The simplest fix would be to add -f to the chown command to ignore files whose ownership cannot be changed. An alternative could be to change the location of the certificate files so they do not fall under a directory that will be chown-ed, but that may have further reaching knock-on effects on things like custom init scripts that assume the current file locations.

[carrodher]

Thank you for opening this issue and submitting the associated Pull Request. Our team will review and provide feedback. Once the PR is merged, the issue will automatically close.

Your contribution is greatly appreciated!

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

[ianroberts]

Still relevant - associated PR is awaiting final review from @migruiz4