search

serversideup / docker-php

🐳 Production-ready Docker images for PHP. Optimized for Laravel, WordPress, and more!
https://serversideup.net/open-source/docker-php/
GNU General Public License v3.0
1.65k stars 108 forks source link

Running the image on Azure and other major cloud providers #372

Closed hajekj closed 1 month ago

hajekj commented 2 months ago

Affected Docker Images

serversideup/php:8.2-fpm-apache ...all images based on v3 using s6-overlay

Current Behavior

As mentioned in #360, when running the image on some managed cloud provider, the container fails to start with:

s6-overlay-suexec: fatal: child failed with exit code 111
s6-rmrf: fatal: unable to remove /run/s6: Permission denied
s6-overlay-suexec: warning: unable to gain root privileges (is the suid bit set?)

and when S6_READ_ONLY_ROOT=1 is set, the container still fails to start with:

s6-overlay-suexec: warning: unable to gain root privileges (is the suid bit set?)
/package/admin/s6-overlay/libexec/preinit: info: read-only root
/package/admin/s6-overlay-3.1.6.2/libexec/preinit: 31: cannot create /run/test of writability: Permission denied
s6-overlay-suexec: fatal: child failed with exit code 2

This is due to the container being started with no_new_priv flag.

Expected Behavior

I would expect the container to run perfectly on major cloud providers like v2.

Steps To Reproduce

  1. Create a new Azure Container Apps environment
  2. Deploy the image there
  3. The container fails to start with the error above

Anything else?

There are currently two workarounds available:

  1. Running the container as root again, which I understand that it is not recommended due to security.
  2. When building the image configuring /run directory to be owned by www-data user which fixes the issue

This is currently from my Dockerfile which just modifies the published image.

USER root
RUN chown -R www-data:www-data /run && \
    chmod -R 755 /run
USER www-data

I believe this mitigation is less invasive than running the container as root. I am up for submitting this change as a PR to fix this in all the images, since it will be much easier to use imho. What are your thoughts on this (I have no clue whether such change would negatively affect extensibility of this image, but since the same operation is performed via s6-overlay I believe it should be okay)?

zgjimgjonbalaj commented 1 month ago

Same issue on Digital Ocean App Platform, can confirm the suggested fix also works here. Thanks!

jaydrogers commented 1 month ago

@zgjimgjonbalaj Try this release and let me know if you have good results: https://github.com/serversideup/docker-php/releases/tag/v3.3.0-beta1

zgjimgjonbalaj commented 1 month ago

@jaydrogers does this tag have that version serversideup/php:beta-8.2-fpm-nginx-alpine?

Edit: Can confirm that the image above is working as expected on Digital Ocean App Platform without having to add the workaround to the Dockerfile.

hajekj commented 1 month ago

Awesome. I am closing the issue, since it got resolved and the linked PR didn't close it. This can be considered resolved.