Add env variables to change UID/GID of www-data

[jan-di]

This PR adds the support for two environment variables that can change the UID/PID of the www-data user dynamically at the entrypoint script. This allows to use a specific uid/gid that is also used on the host to prevent permission issues on bind mounted volumes.

To stay backwards-compatible, the environment variables have the current UID/GID as default value, so they are 3 possible use cases:

• No UID/GID defined, no --user parameter given: Image starts as root, apache/php uses default UID/GID (as before)
• No UID/GID defined, --user parameter given: Image starts as $user, apache/php uses default UID/GID (as before)
• UID/GID defined, no --user parameter given: Image starts as root, apache/php uses defined UID/GID (new)

An additional advantage of changing the UID/GID of www-data instead of creating a new user is, that no config files have to be changed for this - every service can use www-data as before.

This should fix #359, #1081, #1087. See also https://github.com/nextcloud/docker/pull/772#issuecomment-710705819 for more info.

[PrivatePuffin]

I think this is a rather clean solution to the issues at hand, nice work! :)

[jan-di]

Hello @tilosp, i have rebased this PR to the latest changes. Some tests are failing due to database tests, but it seems rather random to me. Could I request a review or is there something other I should do before?

[uchagani]

@tilosp can we get this merged please?

[J0WI]

I'd prefer to use the same approach as in https://github.com/docker-library/wordpress/pull/249 (see also https://github.com/docker-library/wordpress/pull/351 and https://github.com/docker-library/wordpress/pull/371)

[PrivatePuffin]

@J0WI The problem with the Wordpress (and LinuxServer) design, is the fact is isn't compatible with the docker "user" setting. For those two it's acceptable, because the settings is relatively new but for new implementations, like this one, not being able to use docker best-practices is a no-go.

[J0WI]

@Ornias1993 do you refer to something else than docker run --user?

[olivergg]

An alternative solution (or dirty hack ? :sweat_smile: ) would be to use bindfs (on Linux) to mirror the directory on your host and set the permission accordingly, then just use this directory instead of the original one in your docker volume

For example, if you have a MyFiles directory with the UID/GID 1000:1000 then you can create a mirror with the UID/GID changed to 33:33 (www-data by default).

# bindfs -u 33 -g 33 MyFiles MyFilesMirrored

See http://manpages.org/bindfs

[eathtespagheti]

Hoping to see this implemented ASAP

[Fel-o]

any updates?

[djak250]

Is this still on people's radar?

[tushev]

I ended up with building my own, custom Docker image, with

RUN addgroup --gid 1000 --system nextcloud
RUN adduser --uid 1000 --system --disabled-login --disabled-password --gid 1000 nextcloud

And my docker-compose.yml contains

  apache:
    build:
      context: ./images
      dockerfile: Dockerfile-nextcloud-apache
    user: '1000:1000'

[bllngr]

@Kami @tilosp @J0WI, it seems like this is a clean solution to a frequently requested feature and base for other functionality. It also seems to align with Docker best-practices. But there hasn't been any feedback for one year. Is there anything that speaks against rebasing and merging it?

[vincentDcmps]

I'd prefer to use the same approach as in docker-library/wordpress#249 (see also docker-library/wordpress#351 and docker-library/wordpress#371)

in case of you use ldap for connection wordpress approach doesn't work because tou UID is not in /etc/passwd

[PrivatePuffin]

Hey! There is something that bother me in this pr, it's the chown and chgrp. This could lead to multiple issues and I don't think that is the job of a docker image. The sysadmin should know and manually do those changes.

As a side note:

• [ ] Please fix tests
• [ ] Please only edit the root templates docker-entrypoint.sh. The changes are done automatically
• [ ] Could you explain the requirements for the shadow dependency on alpine ? @jan-di

PUID/UID GID/PGID is quite globally used (and not a very good idea considering systems like kubernetes and docker already implement more secure user-setting, for example the docker --user flag or kubernetes runAsUser.). It's goal is 50% setting the user/group and 50% setting the file permisisons.

However, the design here is actually troublesome: No UID/GID defined, --user parameter given: Image starts as $user, apache/php uses default UID/GID (as before)

When --user is set, everything should run as that user. Not run as an arbitrary other/default UID/GID. Regardless of what the UID/GID settings are.

Remember UID/GID env-vars are not a standard! Setting the --user or runAsUser is. So the image should focuss on those users, rather than users using UID/GID.

So in the following case: No UID/GID defined, --user parameter given: Image starts as $user, apache/php uses default UID/GID (as before)

Applications should be running with $user and group.

[J0WI]

closing due #1812