Running as non-root user (Apache Privileged Ports)

[DizzyThermal]

Hi everyone,

I came across this issue about running NextCloud on OpenShift as a non-root user: https://github.com/nextcloud/docker/issues/458

That thread mentioned two PRs made to docker-library/php that were intended to fix the issue. Since the PRs were merged last year to docker-library/php, I figured that using nextcloud:latest would include these changes and there'd be some way to run the apache server on a non-privileged port (i.e., 8080).

A similar thread pointed me to documentation on running as an arbitrary user - where you'd set your RUN_APACHE_USER and RUN_APACHE_GROUP environment variables, but the container is still trying to run on port 80 even with those env variables set: https://github.com/docker-library/docs/tree/master/php#running-as-an-arbitrary-user

When https://github.com/nextcloud/docker/issues/458 was closed, what was the resolution to get the nextcloud image running on OpenShift (as a non-root user, on a non-privileged port)?

Thanks in advance!

[J0WI]

We depend on upstream images. Please have a look at the proposed solutions there:

https://github.com/docker-library/php/issues/94 https://github.com/docker-library/php/pull/174 https://github.com/docker-library/php/issues/771 https://github.com/docker-library/httpd/issues/102

[ghost]

Dangerous superficial knowledge ahead: The problem appears to be that OpenShift isn't able to ignore that EXPOSE setting and it looks like the php-maintainers decided not to do anything about it: https://github.com/docker-library/php/issues/771#issuecomment-451597353

According to the Docker documentation EXPOSE isn't even doing anything:

The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

That's why I'm not sure if special images just to change that EXPOSE instruction are really necessary.

I'm experimenting with these images right now, using Podman instead of Docker, and I can run the apache-image by using "-p 8080:80".

Can someone try this using the "normal" Docker?

[J0WI]

-p 8080:80 works and is used in our examples: https://github.com/nextcloud/docker/blob/master/.examples/docker-compose/insecure/postgres/apache/docker-compose.yml#L16

[ghost]

I'm sorry, I meant that with -p 8080:80 I can run the apache-image as non-root user.

And it looks like that works with Docker too: https://github.com/nextcloud/docker/issues/755#issuecomment-503906730

So the current images work as non-root user and the problem in this case appears to be OpenShift.

[Blackclaws]

Being able to run it from outside via -p 8080:80 is not really saying much as you are redirecting port 80 inside the container to port 8080 outside which you are allowed as a normal user even.

The issue actually is a bit different. The apache inside the container tries to bind on port 80 which it is not allowed to do, as OpenShift in its default form does not allow this privileged operation this fails and the container fails as well.

To fix this issue the apache inside the container should not try to bind to the default port 80 but a higher port such as 8080.

[mschindl]

Is there a solution in sight for the standard image?

I also did a request for enhancement: https://help.nextcloud.com/t/how-to-change-apache-port-for-openshift-4-x-deployment/

[J0WI]

closing due https://github.com/nextcloud/docker/pull/1812#issuecomment-1272547147 and https://github.com/docker-library/php/issues/94

[jukefr]

The first link you provide has little to do with the problem because we are talking about any non-root user which by default in the linux kernel cannot bind to anything bellow 1024 The second link you mention has a sed command as "solution" that probably doesn't even work in 2023. Another "solution" that was mentioned before the issues was closed (and actually resolved) is allowing non root users to bind to ports 0 upwards which shows that the issue is completely not understood on php's side apparently.

Anyways, a concrete solution that does not involve doing anything that goes against (rootless) containerization you can simply bind a file ports.conf with

Listen 1024

to /etc/apache2/ports.conf on the container and it will run on the desired port.