Cannot start SSUPv3 docker image on Google CloudRun

[ivoabx]

Affected Docker Images

serversideup/php:8.2-fpm-nginx-v3.0.1

Docker Labels of the affected images

No response

Current Behavior

After starting the container based on that image in Google CloudRun I get the following error:

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?)

The S6_READ_ONLY_ROOT=1 flag does not seem to help. It results in another error

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

How can this be fixed?

Thanks!

Expected Behavior

It starts the container successfully.

Steps To Reproduce

1. In Cloud Run.
2. Run the image.
3. See the error.

Host Operating System

Cloud Run's host os.

Docker Version

Not 100% sure, but as Cloud Run is on top of kNative GKE it should be containerd.

Anything else?

No response

[jaydrogers]

Can you upgrade to v3.1.1 just to be safe and try again?

I'm not sure if that will fix the issue though.

See the disadvantages of S6: https://serversideup.net/open-source/docker-php/docs/guide/using-s6-overlay#this-disadvantage-of-s6-overlay

You might have to do some extra configuration to get Google Cloud to allow S6 to run.

[slackernrrd]

I have spent the day debugging a similar error using serversideup/php:8.2-fpm-apache-v3.1.0:

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

After reading this blog post https://tomcope.com/tutorial/2020/02/20/docker-setuid-setguid.html I realised my /etc/docker/daemon.js had

{
...
  "no-new-privileges": true,
...
}

Setting --security-opt="no-new-privileges=false" for this container made it start as it should. But I'd prefer not having to disable this security feature.

I'm running this on a CentOS Stream 9 server with standard Docker CE.

[jaydrogers]

Upgrade to v3.1.1 and see if that helps. There were weird permission issues in v3.1.0 with an upstream package dependency that resolved itself.

[slackernrrd]

Upgrading to v3.1.1 didn't help for me. Still need no-new-privileges=false.

[ivoabx]

Thank you both for the advice.

Unfortunately, upgrading to the new version did not solve the issue. I cannot set the --security-opt="no-new-privileges=false" as well, because I have no control over the docker environment in CloudRun.

There were no issues while running SSUPv2 in CloudRun, most probably because the container ran as root.

[skyosev]

I can confirm that this issue occurs on CloudRun, and version 3.1.1 didn't fix it.

[jaydrogers]

Was it ever able to run before, especially with FPM-NGINX?

Out of curiosity, can you get the unit container to run? This one is without S6 Overlay

[skyosev]

Was it ever able to run before, especially with FPM-NGINX?

Out of curiosity, can you get the unit container to run? This one is without S6 Overlay

SSUPv2 runs effortlessly on cloud run. We use it rigth now in production with fpm+nginx. Never tried unit.

[jaydrogers]

If Version 2 of fpm-nginx is running well, then it's not S6.

The problem could be is the container is running as www-data. Try running it as root instead:

############################################
# Base Image
############################################

# Learn more about the Server Side Up PHP Docker Images at:
# https://serversideup.net/open-source/docker-php/
FROM serversideup/php:8.3-fpm-nginx as base

# Run as root for all image stages
USER root

# Set `www-data` as the user to start FPM
RUN echo "user = www-data" >> /usr/local/etc/php-fpm.d/docker-php-serversideup-pool.conf && \
    echo "group = www-data" >> /usr/local/etc/php-fpm.d/docker-php-serversideup-pool.conf

## Uncomment if you need to install additional PHP extensions
# RUN install-php-extensions bcmath gd

############################################
# Development Image
############################################
FROM base as development

# We can pass USER_ID and GROUP_ID as build arguments
# to ensure the www-data user has the same UID and GID
# as the user running Docker.
ARG USER_ID
ARG GROUP_ID

RUN docker-php-serversideup-set-id www-data $USER_ID:$GROUP_ID  && \
    docker-php-serversideup-set-file-permissions --owner $USER_ID:$GROUP_ID --service nginx

############################################
# Production Image
############################################
FROM base as deploy
COPY --chown=www-data:www-data . /var/www/html

[ivoabx]

@jaydrogers Thank you very much for the suggestion.

Running as root, along with setting user and group to www-data for fpm solved it.

It's still not rootless, but at least we're now able to migrate to the newest version.

Issue could be closed, I think.

Cheers, Ivo