Openshift support for non root container?
dakkusingh opened this issue · comments
[05-Oct-2018 23:18:06] ERROR: failed to open error_log (/opt/bitnami/php/logs/php-fpm.log): Permission denied (13)
--
| [05-Oct-2018 23:18:06] ERROR: failed to post process the configuration
| [05-Oct-2018 23:18:06] ERROR: FPM initialization failed
Hello @dakkusingh,
Thanks for reporting the issue. Adding non-root support to the php-fpm container is something that we will work soon. I will update this issue once we release the non-root version.
I derived an image from bitnami/php-fpm:7.3-prod in which I created a non-root user (for a requirement unrelated to this issue) which is then used to run the image. It worked after I made the following permissions changes
- readable and writable for the group of my user:
/opt/bitnami/php/var(including subdirectories)/opt/bitnami/php/tmp
- readable for the group of my user:
/opt/bitnami/php/etc- this step was only necessary because I copied files to subdirectories and the files do not have read permission for "other"
Additionally, I made /opt/bitnami/php/logs/php-fpm.log a symlink to /dev/stdout. This makes it easier to check the logs in Kubernetes. It would also work if you make this file writable to the group of your user.
I am not sure how to create a general approach for a non-root user image from this steps. But if it is no security concern to make the mentioned directories writable for all users, that would be an easy solution to provide a non-root version of the container.
Hi @tompizmor,
is there a reason why only the rhel-7 versions are non-root? All the other images we use / extend are based on Debian 9 (minideb). Would be nice to have the same base for all images.
Hi,
We had several tickets with user experience issues, especially when using persistence, in other containers that are non-root. That's the reason we are slowly doing the transition. However, there are plans for doing the non-root transition for more containers. We cannot give an ETA but stay tuned :)
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.
I derived an image from
bitnami/php-fpm:7.3-prodin which I created a non-root user (for a requirement unrelated to this issue) which is then used to run the image. It worked after I made the following permissions changes
readable and writable for the group of my user:
/opt/bitnami/php/var(including subdirectories)/opt/bitnami/php/tmpreadable for the group of my user:
/opt/bitnami/php/etc- this step was only necessary because I copied files to subdirectories and the files do not have read permission for "other"
Additionally, I made
/opt/bitnami/php/logs/php-fpm.loga symlink to/dev/stdout. This makes it easier to check the logs in Kubernetes. It would also work if you make this file writable to the group of your user.I am not sure how to create a general approach for a non-root user image from this steps. But if it is no security concern to make the mentioned directories writable for all users, that would be an easy solution to provide a non-root version of the container.
@jgerken is there a repo where I could see your workaround ? I am struggling with same issue with php-fpm 7.4 ... Thanks !
@barein its in a private company repo, but I can extract the relevant parts from it and post them here in the afternoon. I hope they work with the 7.4 version, too.
Thanks @jgerken it would be great !
Here is my configuration for the 7.3 version. You need to replace the placeholders <GROUP_ID> etc. with the values you need / want for your setup. Having a user with the same ID on the host is a nice to have (because when you run top on that machine the processes are then associated to the same username) but not necessary. The user I created has a home directory in the Docker container because it has to run git commands and git likes it better when the user has a home directory. Depending on your use case you could also skip the creation of the home directory (i think the flag is --no-create-home).
After creating the group and the user I give group-write-access to the directories which caused trouble for me when trying to run the container in non-root mode and change the group of the directories to the group I created in the first step.
In the last step, the php-fpm log file is linked to stdout as the container runs in a Rancher based Kubernetes setup and Rancher makes the stdout available als logs directly in its UI. Depends on your setup if you need this step or not.
I hope this helps and works for 7.4, too :)
# create user and group
RUN addgroup --gid <GROUP_ID> <GROUP_NAME> \
&& adduser \
--system \
--uid <USER_ID> \
--gid <GROUP_ID> \
--disabled-password \
--disabled-login \
<USER_NAME> \
# enable non-root user usage
&& chmod -R g+w /opt/bitnami/php/var /opt/bitnami/php/tmp \
&& chgrp -R <GROUP_NAME> \
/opt/bitnami/php/var \
/opt/bitnami/php/tmp \
&& ln -s /dev/stdout /opt/bitnami/php/logs/php-fpm.log
USER <USER_NAME>Thanks @jgerken ! I'll give a try very soon :)
@jgerken it worked :) thanks !
In my case to make it work I just had to also change group write access of /opt/bitnami/php/logs/
For people who might be interested I made a Gist of that : https://gist.github.com/barein/13d45c431a1d83c704bb5707fdc6577c
Thanks for letting us know and for sharing your result here, I am sure it will be useful for more users in the community!
Are there any plans to add support for setting the running user via UID? Having to choose the user in the Dockerfile won't be suitable for a distributed image.
Hi, can you explain a little bit your specific use case? In the end, the UID can be set when deploying this image using a docker-compose or a Helm Chart, but depending on the use case and the user needed (basically the permission/group for that user) you will face issues or not
I have a PHP application which needs to write logs to a directory. This directory is mounted via docker compose to the host so I can access the logs without having to enter the container:
volumes:
- ./logs:/app/storage/logs
The problem is, that the deamon user (UID 1) running PHP inside the container can't write to the mounted directory, because it is owned by the user running the container, for example root (UID 0). What's the best way to get this working without having to change FPM configs?
You should set the proper permissions to the directory on your host machine, as those permission are shared between the host and the container. In that case, if the user that needs to write in that folder is daemon, you should change the permission to make this directory writable by daemon
That's the way I used to solve this problem, but I think it introduces security holes if I have to open a directory for writing to a whole group or everyone. So there is no other way to solve this?
Hi @Kovah
I am afraid there is no other alternative, at least that I am aware of, when mounting a volume from the host rather than using the permissions expected by the image.
If the image is a "root" container (executed as "UID 0" by default) and, as you said, it creates/uses a different user to execute Apache/Nginx (e.g. user "daemon" or "www-data"), then you need to ensure that user has permissions to write in the volume.
If the image is a "non-root" container (executed by default as "UID X", where X != 0) such as the Bitnami NGINX container, then it will use the same UID to run both the container and the process that runs NGINX. In this case, you need to ensure that users has permissions to write in the volume.
What I did was to simply bind the mounts to get this to work, for my use case:
version: "2.4"
services:
php_fpm:
image: bitnami/php-fpm:7.4
user: "33:1001"
volumes:
- ./app:/app
- ./volumes/php_fpm/logs:/opt/bitnami/php/logs
- ./volumes/php_fpm/tmp:/opt/bitnami/php/tmpIn order to unify the approaches followed in Bitnami containers and Bitnami charts, we are moving some issues in bitnami/bitnami-docker-<container> repositories to bitnami/containers. Please follow bitnami/containers to keep you updated about the latest bitnami images.
If this issue is still applicable, please feel free to recreate it at https://github.com/bitnami/containers/issues/new/choose
More information here: https://blog.bitnami.com/2022/07/new-source-of-truth-bitnami-containers.html