[Bug]: Unable to run Elasticsearch with restrictive umask

Module

Elasticsearch

Testcontainers version

1.17.6

Using the latest Testcontainers version?

Yes

Host OS

Linux

Host Arch

x86_64

Docker version

Client: Docker Engine - Community
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:08 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:25:58 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.14
  GitCommit:        9ba4b250366a5ddde94bb7c9d1def331423aa323
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

I have a similar problem as discussed in ticket #4952 but for Elasticsearch. Elasticsearch fails to start with the following error:
Exception in thread "main" java.nio.file.AccessDeniedException: /usr/share/elasticsearch/config/jvm.options.d/ elasticsearch-default-memory-vm.options
Testcontainers library copies elasticsearch-default-memory-vm.options file into elasticsearch container with default file permissions which in my case is -rw------- because umask in my computer is set to 077. As uid and gid in my computer are different than those in elasticsearch container, this file is not accessible by elasticsearch and the mentioned error is thrown.

I guess the solution should be similar as in #5401 where temporary file is created with predefined permissions which allow reading the file for everyone instead of default permissions.

Relevant log output

No response

Additional Information

No response

Empieza rastreando el código del módulo de Elasticsearch que copia elasticsearch-default-memory-vm.options en el contenedor; después, compara su gestión de archivos temporales con la solución analizada en los issues #4952 y #5401. Reproduce el fallo con umask 077 y verifica que Elasticsearch se inicia y puede leer el archivo copiado.