WIP: introduce unprivileged images

[smueller18]

Following Docker best practices, all images should run as non-root user. This PR introduces

1. an unprivileged variant for each of the existing nextcloud images so that the existing images will not have breaking changes
2. replacement of nginx image with nginxinc/nginx-unprivileged
3. replacement of nextcloud images in the example docker-compose files with unprivileged variants

Todos:

• Use non-root images for postgres, mariadb and redis in example docker-compose files
• Test each example docker-compose
• Maybe update readme with unprivileged images
• Implement new image tags (e.g. nextcloud:unprivileged)

Closes#760

[EWouters]

Nice work!

[pierreozoux]

This is indeed nice.

Could you separate your PR on 2 commits, one with the changes and one with the update.sh?

This makes it easier to review.

Thanks :)

[smueller18]

@pierreozoux I did a rebase on the latest master commit and seperated the changes into two seperat commits.

In the meantime, I changed my mind and think it is not worth the effort to support both, privileged and unprivileged container images. The default one should always be unprivileged. With that in mind, I stopped working on this PR because it is not target-oriented for me.

[pierreozoux]

You are right, everything should be unpriviledged and readonly, imho too :)

[tilosp]

wouldn't it be enough to add a environment var, that changes the port? Running as an unprivileged user is already possible with --user.

[smueller18]

Using the --user option is possible for the fpm image but not for the apache image because port 80 is binded by default. Replacing port 80 with 8080 during runtime in the entrypoint based on an environment variable is not possible because the responsible file /etc/apache2/ports.conf is owned by root. So either it has to be changed during build time (as introduced in this PR) or ports.conf must be mounted during runtime which is not user friendly.

[jan-di]

wouldn't it be enough to add a environment var, that changes the port? Running as an unprivileged user is already possible with --user.

Additionally to what @smueller18 said, there are a few more cases where nextcloud don't work right when you set the --user parameter. For example (at least, with the apache image):

• Redis cannot be used:
  /entrypoint.sh: 56: /entrypoint.sh: cannot create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied
• Apache IP-Rewrite cannot be disabled (as recommended when running behind a reverse proxy):
  Could not remove /etc/apache2/conf-enabled/remoteip.conf: Permission denied

I think the only clean solution to this would be to make the entrypoint script aware for UID/GID env variables. The entrypoint could make the changes above as root and then start the services under the unprivileged UID/GID. I think this is described in #359

[J0WI]

closing due #1812