Write permission required on /etc/nginx

[eerotki]

I'm using nginxinc/nginx-unprivileged:alpine in Docker to run Nginx non-root. During the build in Dockerfile, I restrict /etc/nginx folder to read & execute permissions only with chmod 555 -R /etc/nginx, so that no running config could be altered. Due to changes after 1.17.10 I'm experiencing unexpected behavior, where the build fails on start up with message:

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: Can not modify /etc/nginx/conf.d/default.conf (read-only file system?), exiting
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-configure-nginx-unprivileged.sh
sed: can't create temp file '/etc/nginx/conf.d/default.confXXXXXX': Permission denied

If I grant write permissions on /etc/nginx/conf.d the build will fail with message:

sed: can't create temp file '/etc/nginx/nginx.confXXXXXX': Permission denied

So I assume Nginx now requires write permissions on /etc/nginx. Is this behaviour intentional and expected?

I would like to retain my setup and deny write permissions on config folders.

[alessfg]

Heya! Can you pull the latest version of the image and let me know if that works? The scripts should no longer need write access to nginx.conf 😄

[eerotki]

Indeed, this certainly is fixed with the latest version. I should had made certain that no old images are being used before posting this issue. Oh well, happens.

Thanks for the quick reply and your help!

[jalaziz]

It seems that write access is required for nginx.conf in the latest version. I get that it's required for the scripts to modify the file, but isn't providing write access to nginx.conf to the nginx user technically a security risk?

That being said, I can't think of a great solution other than possible some suid hackery.

[alessfg]

Truth be told, I can't find what alleged fix was introduced to initially solve this issue, and it's been long enough that I have totally forgotten.

You are right that the image as is requires write access to nginx.conf. This adds quite a bit of adaptability insofar as supported environments goes, and, in theory this should not be a security issue if you are running the images as intended. That being said, there might be a case for providing a less customizable and more restricted image.

[jalaziz]

in theory this should not be a security issue if you are running the images as intended.

Well, even when running as intended, if an attacker discovered an exploit wouldn't it be theoretically be possible to change the config maliciously and force a reload? Or is that impossible?

[alessfg]

It would be theoretically possible, although at that stage changing the NGINX config would probably be one of your lesser worries.

But, like I said, you raise a valid point for providing a more restricted image. I don't know that it'll 100% happen, or when it will happen, if it does happen, but it's definitely an option to be explored.

In the meantime, and if it's something you'd really like to see implemented, PRs are always more than welcome!