containers [bitnami/php-fpm] Is there a reason to run php-fpm docker image as root user?

Name and Version

bitnami/php-fpm:8.1.9-debian-11-r9

What steps will reproduce the bug?

Just pulled the image from registry.

What is the expected behavior?

No response

What do you see instead?

After some time I decided to upgrade php-fpm image and I've noticed that image doesn't run as "I have no name!" user like it used to before with earlier bitnami php-fpm images but "root" user.

Why did you decided so?

Additional information

And also I've started to have issues with php not being able to write to directories in my app.

Aug 30 '22 13:08 dominikkrulak

Hi,

Right now, we have the policy that development containers (python, ruby, java, php) have the root user, essentially to ease the development process. However, this is something to be reviewed in the future. Thank you so much for the feedback!

Sep 01 '22 08:09 javsalgar

Well, why don't build for production only? We usually (always) build staff for production with security in mind. That way we don't have to struggle twice when moving from development to staging or production.

If someone wants to debug for example php application than that someone can extend a php image with xdebug module.

Personally I prefer to work and experiment with production image because of restrictions made for production.

Anyway, keep up good work and thank you for your respond!

Sep 01 '22 08:09 dominikkrulak

We were using the php-fpm:8.0 image for some time now, instead of our custom build php binary and images. This worked fine on our Kubernetes cluster, where all production resources are executed with unprivileged user. This worked fine up until recentely were we are getting the following error when starting the container:

docker run -it internal-image:internal-tag                                
[13-Sep-2022 14:44:59] ERROR: failed to open error_log (/opt/bitnami/php/logs/php-fpm.log): Permission denied (13)
[13-Sep-2022 14:44:59] ERROR: failed to post process the configuration
[13-Sep-2022 14:44:59] ERROR: FPM initialization failed

Upon further investigation, I noticed an older image (and SHA) did work. When I inspect the image I see the following:

New(er):

I have no name!@e7b3c066d00e:/opt/bitnami/php$ ls -la
total 48
drwxr-xr-x 12 root root 4096 Sep 12 17:29 .
drwxrwxr-x  6 root root 4096 Sep 12 17:55 ..
drwxr-xr-x  2 root root 4096 Sep 12 17:29 bin
drwxr-xr-x  4 root root 4096 Sep 12 17:29 etc
drwxr-xr-x  3 root root 4096 Sep 12 17:29 include
drwxr-xr-x  3 root root 4096 Sep 12 17:29 lib
drwxr-xr-x  2 root root 4096 Sep 12 17:29 licenses
drwxr-xr-x  2 root root 4096 Jan  1  1970 logs
drwxr-xr-x  3 root root 4096 Sep 12 17:29 php
drwxr-xr-x  2 root root 4096 Sep 12 17:29 sbin
drwxr-xr-x  2 root root 4096 Jan  1  1970 tmp
drwxr-xr-x  4 root root 4096 Sep 12 17:29 var

Old:

root@6588547f93a3:/app# ls -la /opt/bitnami/php
total 48
drwxr-xr-x 12 1000 1000 4096 Jun  6 21:33 .
drwxr-xr-x  1 1000 1000 4096 Jun  6 21:33 ..
drwxr-xr-x  2 1000 1000 4096 Jun  6 21:33 bin
drwxr-xr-x  4 1000 1000 4096 Jun  6 21:33 etc
drwxr-xr-x  3 1000 1000 4096 Jun  6 21:33 include
drwxr-xr-x  3 1000 1000 4096 Jun  6 21:33 lib
drwxr-xr-x  2 1000 1000 4096 Jun  6 21:33 licenses
drwxr-xr-x  2 1000 1000 4096 Jan  1  1970 logs
drwxr-xr-x  3 1000 1000 4096 Jun  6 21:33 php
drwxr-xr-x  2 1000 1000 4096 Jun  6 21:33 sbin
drwxr-xr-x  2 1000 1000 4096 Jan  1  1970 tmp
drwxr-xr-x  4 1000 1000 4096 Jun  6 21:33 var

It appears the directories of PHP are now also owned by root, instead of the 1000 unprivileged user. Is this something we can get fixed, or do we need to chown those directories ourselves in our Dockerfile (that would be a cumbersome approach)

@javsalgar

Are there "production" PHP containers available? As it's just the runtime of course :)

Sep 13 '22 14:09 xvilo

@xvilo if you recursively change owner of the php directory to e.g. 1001 than you must run php process as user 1001 to avoid write permissions or ease permissions (not good). And you may encounter more problems digging deeper down the hole (see my last paragraph).

Latest bitnami/php-fpm image is build to run as root.

Right now, we have the policy that development containers (python, ruby, java, php) have the root user, essentially to ease the development process. However, this is something to be reviewed in the future. Thank you so much for the feedback!

When I was trying to adjust it back to user 1001 I encountered on write permissions in my application. Currently all my application's directories are owned by root with eased permissions because php process is run as deamon user and each recorded write is owned by deamon. If I wouldn't ease write permissions than php system user deamon wouldn't have write permission to a directory owned by root.

I don't want to tweak things around for now and adjust user 1001 to match user 1001 on another container or chown wherever is needed just to make it work. I hope bitnami's staff will make php-fpm image for production soon. Otherwise tweaking is up next.

Sep 14 '22 16:09 dominikkrulak

Hi @xvilo

I'd like to traceback the change you mentioned, Do you have the older SHA or image tag?

Sep 15 '22 07:09 fmulero

@fmulero good one, we were using bitnami/php-fpm:8.0 as base image. Which "broke" due to the permissions thingy. I can't view the last build logs because of a botched GitLab upgrade. But I can provide the following info:

The last working build of our image with bitnami/php-fpm:8.0 as base was at: Aug 26, 2022 1:55pm GMT+0200 for us.
The first non-working build was at Sep 1, 2022 10:55am GMT+0200.
There were no builds in between.
A current workaround for us, is to use FROM bitnami/php-fpm:8.0.19 instead. This is an older build, which does work.
When doing docker image inspect [private image], I do get the following info:

"Created": "2022-08-26T11:57:03.058806422Z",
"Labels": {
    "org.opencontainers.image.authors": "https://bitnami.com/contact",
    "org.opencontainers.image.description": "Application packaged by Bitnami",
    "org.opencontainers.image.ref.name": "8.0.22-debian-11-r9",
    "org.opencontainers.image.source": "https://github.com/bitnami/containers/tree/main/bitnami/php-fpm",
    "org.opencontainers.image.title": "php-fpm",
    "org.opencontainers.image.vendor": "VMware, Inc.",
    "org.opencontainers.image.version": "8.0.22"
}

Is this enough info the help you further?

Sep 15 '22 07:09 xvilo

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.

Oct 01 '22 01:10 github-actions[bot]

I will check on Monday if this is still an issue

Oct 01 '22 06:10 xvilo

Behaviour for bitnami/php-fpm:8.0 is still broken. Specifically using bitnami/php-fpm:8.0.19 does work as "before". Can we mark this issue so it wont become stale every x days?

Oct 12 '22 16:10 xvilo

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.

Oct 28 '22 01:10 github-actions[bot]

please dont.

Oct 28 '22 05:10 xvilo

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.

Nov 14 '22 01:11 github-actions[bot]

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.

Nov 20 '22 01:11 github-actions[bot]

Reopen please

Nov 20 '22 07:11 xvilo

The behaviour was changed here, because the owner of the folder was changing without control (there are images with the owner 1000 or 1001 ), depending on the permissions inside of the tar file.

I am discussing this topic internally, could you share more details about how are you running your app?

Dec 07 '22 16:12 fmulero

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.

Dec 23 '22 01:12 github-actions[bot]

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.

Dec 29 '22 01:12 github-actions[bot]

Sorry, I'm on holidays. Will comment about it in the new year. Can it be reopened? The boy is quite annoying this way.

Dec 29 '22 09:12 xvilo

I am currently doing to the following workaround so the www pool runs as a user instead of root. There is a /opt/bitnami/php/etc/common.conf file which contains the following contents:

user=deamon
group=deamon
listen.owner=deamon
listen.group=deamon

I changed the user and group to my own user and group (all non-root). This is my docker-compose setup:

  php81:
    image: bitnami/php-fpm:8.1
    restart: unless-stopped
    volumes:
      - /srv/webapps:/srv/webapps
      - /srv/common.conf:/opt/bitnami/php/etc/common.conf

Feb 28 '23 22:02 yoramdelangen

don't you have any issue with that @yoramdelangen ? /opt/bitnami/php files and folders are owned by root.

Mar 23 '23 10:03 hanhpv

@hanhpv no, I didn't. I think because of the custom mount, and the PHP is still started with root but starts the PHP pool as deamon

Mar 24 '23 07:03 yoramdelangen