Currently the Docker images for Nextcloud do not apply available upstream security updates when the image is being built. E.g. currently the latest stable-apache image, which was built just 2 hours ago, does not have this Debian security fix (released on August 31st) installed:
https://www.debian.org/security/2020/dsa-4757
IMO, it would be much easier and safer for everybody to apply any available upstream package updates while building the official image, rather than forcing users to apply updates inside the image or build their own image based on the official one, just to be sure that security updates are installed.
I fully understand and have no problem with the explanation given for #623, but I do not think that it is a good idea to rely on upstream Docker images having these updates applied promptly.
For Debian-based images this should be sufficient:
diff --git a/19.0/apache/Dockerfile b/19.0/apache/Dockerfile
index c77835a..034e6a8 100644
--- a/19.0/apache/Dockerfile
+++ b/19.0/apache/Dockerfile
@@ -5,6 +5,7 @@ FROM php:7.4-apache-buster
RUN set -ex; \
\
apt-get update; \
+ apt-get upgrade -y; \
apt-get install -y --no-install-recommends \
rsync \
bzip2 \
For Alpine-based images I believe the respective change would be:
diff --git a/19.0/fpm-alpine/Dockerfile b/19.0/fpm-alpine/Dockerfile
index 55a0b20..ab23617 100644
--- a/19.0/fpm-alpine/Dockerfile
+++ b/19.0/fpm-alpine/Dockerfile
@@ -4,6 +4,8 @@ FROM php:7.4-fpm-alpine3.12
# entrypoint.sh and cron.sh dependencies
RUN set -ex; \
\
+ apk update --no-cache; \
+ apk upgrade --no-cache; \
apk add --no-cache \
rsync \
; \
Doing apt upgrade or the equivalent for other package managers is considered bad practice. https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#run
As I understand that doc, they are advising against it due to the possibility of some Debian "essential" package upgrades failing when run inside a Docker container. Obviously the base image should be updated instead, but IRL that is not always possible.
Doing the "apt-get upgrade" will not break anything in the vast majority of cases, because either there are no updates at all or there is an update that will apply just fine. If it does break, then this is a good way to find out that the base image is not up to date. In fact I would probably prefer not building a new image at all until the base image is updated with that essential package security update, because this brings attention to the problem.
IMO, having security updates applied is far more important than avoiding the potential extra hassle of occasionally dealing with breakage.
Any update on this issue? I was also wondering why I get a 'not patched' warning from https://scan.nextcloud.com after using the :latest nextcloud docker image...
I also face the issue right now that I basically cannot use the docker image, as it is outdated :-(
This is a security issue for any deployed instance that is based on the docker image, please fix this.
I agree with the security concerns, although I am not sure if applies in this case. The vulnerabilities in https://www.debian.org/security/2020/dsa-4757 mainly affect configurations using HTTP/2. This usually involves using the _*-fpm_ Nextcloud images, which would mean using a separately up to date Apache/httpd image.
Out of date images are somewhat inherent with the stacked-build design of Docker images, when you are not building all of the layers yourself. It is possible to create, build and test a custom Dockerfile that inherits the out of date _*-apache_ Nextcloud image and just runs apt upgrade -y for use until the official image catches up.
EDIT2: The Nextcloud images do appear(?) to rebuild the _php:7.4-apache-buster_ images they are based upon: Image Layer Details - nextcloud:19.0.3-apache.
Hi Stephen,
Thanks for the answer, however I cannot agree with you here.
"Out of date images are somewhat inherent with the stacked-build design of Docker images, when you are not building all of the layers yourself." - I don't see this like you, you could always add the upgrade step in the dockerfile as a separate layer, which makes sure that everything is up to date.
"and just runs apt upgrade -y for use until the official image catches up." - but this goes against everything that you want to create with docker, namely an infrastructure without configuration drift and the ability to recreate the infra from scratch and having everything stored properly as Config as Code. If I have to start to patch my docker containers, the whole setup is basically doomed from the start.
While this vulnerability might not affect this image, you cannot make sure that this is also true for all other vulnerabilities.
Also nobody expects that he has to manually patch their containers, this goes against best practices.
See also here:
I really like nextcloud and would like to use it in the public internet, it would be really great if you could enhance the security process here and provide up to date base images :-)
Can't quite follow your discussions, guys. Can you summarize for me? I'm just a casual :D
Will the docker run nextcloud:latest result in a fully patched nextcloud or not in the future?
@JustACasual This issue is about ensuring that when the Nextcloud Docker image is built, then it has all the currently available security updates applied. What happens an hour/day/week/year after the image is built is a whole other discussion.
In our layer, we're just maintaining security updates for Nextcloud itself. All other dependencies, namely Apache or PHP, are maintained here: https://github.com/docker-library/php
As soon as there is a new version for any of the base images all Nextcloud images are rebuild automatically.
@J0WI that's nice and I can see how in theory this should give up to date images, but as we have seen in reality that's not always the case.
I don't really understand what would be the downside of ensuring that all available security updates are installed at image build time?
Most helpful comment
As I understand that doc, they are advising against it due to the possibility of some Debian "essential" package upgrades failing when run inside a Docker container. Obviously the base image should be updated instead, but IRL that is not always possible.
Doing the "apt-get upgrade" will not break anything in the vast majority of cases, because either there are no updates at all or there is an update that will apply just fine. If it does break, then this is a good way to find out that the base image is not up to date. In fact I would probably prefer not building a new image at all until the base image is updated with that essential package security update, because this brings attention to the problem.
IMO, having security updates applied is far more important than avoiding the potential extra hassle of occasionally dealing with breakage.