Introduced redis session handler does not work with non-root images

[smueller18]

In commit 83ea69d, a redis session handler was intrododuced. But the file /usr/local/etc/php/conf.d/redis-session.ini can not be written when using a non-root image, because the folder is owned by root and the default www-data user does not have write permission.

/var/www/html # ls -lha /usr/local/etc/php/conf.d
total 72
drwxr-xr-x    1 root     root        4.0K Feb 26 08:50 .
drwxr-xr-x    1 root     root        4.0K Feb 26 07:34 ..
-rw-r--r--    1 root     root          35 Feb 26 08:50 docker-php-ext-apcu.ini
-rw-r--r--    1 root     root          18 Feb 26 08:47 docker-php-ext-exif.ini
-rw-r--r--    1 root     root          16 Feb 26 08:47 docker-php-ext-gd.ini
-rw-r--r--    1 root     root          21 Feb 26 08:50 docker-php-ext-imagick.ini
-rw-r--r--    1 root     root          18 Feb 26 08:48 docker-php-ext-intl.ini
-rw-r--r--    1 root     root          18 Feb 26 08:48 docker-php-ext-ldap.ini
-rw-r--r--    1 root     root          23 Feb 26 08:50 docker-php-ext-memcached.ini
-rw-r--r--    1 root     root          82 Feb 26 08:48 docker-php-ext-opcache.ini
-rw-r--r--    1 root     root          19 Feb 26 08:48 docker-php-ext-pcntl.ini
-rw-r--r--    1 root     root          23 Feb 26 08:49 docker-php-ext-pdo_mysql.ini
-rw-r--r--    1 root     root          23 Feb 26 08:49 docker-php-ext-pdo_pgsql.ini
-rw-r--r--    1 root     root          19 Feb 26 08:50 docker-php-ext-redis.ini
-rw-r--r--    1 root     root          20 Feb 26 07:34 docker-php-ext-sodium.ini
-rw-r--r--    1 root     root          17 Feb 26 08:49 docker-php-ext-zip.ini
-rw-r--r--    1 root     root          18 Feb 26 08:50 memory-limit.ini
-rw-r--r--    1 root     root         189 Feb 26 08:50 opcache-recommended.ini

For running my nextcloud image, I use the default non-privileged user www-data.

/var/www/html $ id
uid=82(www-data) gid=82(www-data) groups=82(www-data)

[smueller18]

Here is a command to reproduce this behavior:

» docker run --rm -it --user www-data nextcloud:fpm-alpine sh
/var/www/html $ NEXTCLOUD_ADMIN_USER=admin NEXTCLOUD_ADMIN_PASSWORD=admin NEXTCLOUD_UPDATE=1 REDIS_HOST=localhost /entrypoint.sh sh -c 'echo $?'
Configuring Redis as session handler
/entrypoint.sh: line 26: can't create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied
Initializing nextcloud 16.0.1.1 ...
Initializing finished
New nextcloud instance
running web-based installer on first connect!

[Unb0rn]

Any workarounds? I have this problem too

[J0WI]

Thanks for reporting this. I can reproduce the issue, but I'm not very happy with the proposed permission change in #764.
However, this should not break your NextCloud, you just have no Redis session handler. As a workaround, you can mount a redis-session.ini manually.

[smueller18]

I know changing the permissions is kind of a security issue. But running the image as root is even more.

What definitely does not work:

1. Writing configuration in .user.ini file. According to PHP memory limit to 128 ? #447 (comment), this does not work for CLI mode.

Here are some options that I figured out:

1. Change ownership of /usr/local/etc/php/conf.d/ to user www-data. The entrypoint creates redis-session.ini. Results in security concerns.
2. Create placeholder file /usr/local/etc/php/conf.d/redis-session.ini in the Dockerfile with no content. Change ownership of only /usr/local/etc/php/conf.d/redis-session.ini to user www-data. Content can be written in the entrypoint. More secure than 1. but if redis is not used, there is an empty file.
3. Create file /usr/local/etc/php/conf.d/session.ini in the Dockerfile with defaults from default config /usr/local/etc/php/php.ini-production. Change ownership of only /usr/local/etc/php/conf.d/session.ini to user www-data. Content can be replaced with sed in the entrypoint. Security equal to 2. but duplicate config for session.
4. Only write /usr/local/etc/php/conf.d/redis-session.ini when running as root, otherwise log a warning that the file must be mounted manually instead of throwing the error like described above. No security concerns.

Currently I think version 3 is the best trade-off. @J0WI what do you think?

[J0WI]

Why would you prefer 3 over 2?
4 would also be an option for me, this is basically what happens now.

@tilosp what is your opinion?

[smueller18]

@J0WI I prefer 3 over 2 because if redis host is not set, there is a file called redis-session.ini which might irritate users.
Best practices of writing Docker images says

If a service can run without privileges, use USER to change to a non-root user.
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user

All images in this project should run as non-root by default. Having this in mind, 4 is not an option. I will open a new PR that sets non-root users as default for all used images and examples. Not choosing 4 is a precondition for that.

[tilosp]

1 and 2 are not really an option because it wouldn't work for users other than root and www-data. Instead we would need to chmod 777 them.

It there any difference between 1, 2 and 3 in terms of security? In each case php can modify it's own config.

All images in this project should run as non-root by default. Having this in mind, 4 is not an option. I will open a new PR that sets non-root users as default for all used images and examples. Not choosing 4 is a precondition for that.

The web server already runs as a non-root user (www-data) by default.
And i don't see how adding USER www-data to the Dockerfile will improve the security. If you don't trust the container to run apache as www-data you also can't trust the default user to be www-data.

[J0WI]

It there any difference between 1, 2 and 3 in terms of security?

Not it terms of security, but I'd avoid changing upstream files.

[smueller18]

The web server already runs as a non-root user (www-data) by default.

I can't verify that, have a look at the commands:

• FPM

» docker run --rm -it --name nextcloud -d nextcloud:fpm-alpine
b24abcf965ff7b7027bfa2d6e7295898e368ea9aba2a56332c301a3b1a7ad267

» docker exec -i -t nextcloud ps aux                          
PID   USER     TIME  COMMAND
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   35 www-data  0:00 php-fpm: pool www
   36 www-data  0:00 php-fpm: pool www
   37 root      0:00 ps aux

• Apache

» docker run --rm -it --name nextcloud -d nextcloud
7f64940a1f4db036e821432d4a53ba937a32ae5a25093a94ad09073348f29e16

» docker exec -i -t nextcloud ps aux               
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  3.8  0.4 496432 35640 pts/0    Ss+  20:07   0:00 apache2 -DFOREG
www-data    45  0.0  0.1 496464  9380 pts/0    S+   20:07   0:00 apache2 -DFOREG
www-data    46  0.0  0.1 496464  9380 pts/0    S+   20:07   0:00 apache2 -DFOREG
www-data    47  0.0  0.1 496464  9380 pts/0    S+   20:07   0:00 apache2 -DFOREG
www-data    48  0.0  0.1 496464  9380 pts/0    S+   20:07   0:00 apache2 -DFOREG
www-data    49  0.0  0.1 496464  9380 pts/0    S+   20:07   0:00 apache2 -DFOREG
root        50 22.0  0.0  36632  2804 pts/1    Rs+  20:07   0:00 ps aux

The PID 1 process always runs as root by using the defaults.

And i don't see how adding USER www-data to the Dockerfile will improve the security. If you don't trust the container to run apache as www-data you also can't trust the default user to be www-data.

Have a look at the following blog post. There is a good explanation, why running images as root is not a good practice:

Containers that run as root frequently have far more permissions than their workload requires which, in case of compromise, could help an attacker further their attack.
https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#8-run-containers-as-a-non-root-user.

If the USER directive is set to www-data the attack vector is minimized when running with defaults. And if anyone wants to run the image as root this is still possible by manually changing the user.

1 and 2 are not really an option because it wouldn't work for users other than root and www-data. Instead we would need to chmod 777 them.

It makes no sense to use another user than root or www-data to run fpm or apache, other users do not have sufficient permissions.

How should we go an with this issue?

[tilosp]

I can't verify that, have a look at the commands:

Yes the entrypoint scipt and apache/fpm master process run as root by default. I meant that the processes that handle the requests and run the php code are run by a different user.

If the USER directive is set to www-data the attack vector is minimized when running with defaults. And if anyone wants to run the image as root this is still possible by manually changing the user.

Yes it will reduce the attack surface in case there is a bug in apache/fpm that allows code execution in the master process. But it won't help in the case of a malicious docker image. To protect against a malicious docker image you would need to override to default user for example in the docker-compose file.

Something like this should be done upstream in the php base image, then all php based images get the benefit.

It makes no sense to use another user than root or www-data to run fpm or apache, other users do not have sufficient permissions.

This is valid use case and it is supported by the upstream image. It should work, have you tried it? If there is a permission problem it is a bug.

[smueller18]

I was not aware of that in docker-library/php#787 the permissions of folder /var/www/html were set to 777. So yes, every user can be used to run the php-fpm image.

I guess the upstream images will not set the user directive in the mid-term because that will break too many existing child images. So in my opinion, this should be treated proactive from the application side.

After the discussions above, how should we follow?
In the meantime, I am just happy if the entrypoint does not throw an exception anymore. And all following changes of this project should work user independent so that updating the image is always possible without manual testing in a sandbox environment.