Pre-create "wp-content" (and subdirectories) with wide permissions for users who bind-mount directly into them

[tianon]

Fixes #436
Closes #474

This is an alternative to #474 that doesn't revert the intent of #74, but still provides a fix for #436.

[yosifkit]

While the 777 directory is "insecure" for normal host setups, there are not other processes or users in the container so this is equivalent to 700 for normal usage but still allows for any user ID to be the "owner" by using --user when running the container.

[MorgusLethe]

Expected:
The title of this fix suggests the subdirectories of wp-content such as plugins, themes and uploads would be pre created and have wide permissions.

Actual:

uploads directory is not pre-created as far as I can tell, which results in it being created at container creation and therefore owned by root:root (same issue as #436 that this change is supposed to fix). The other two are owned by www-data as expected.

Reproduction:

My docker compose file looks like this:

...
#service level
volumes:
      - plugins:/var/www/html/wp-content/plugins
      - themes:/var/www/html/wp-content/themes
      - uploads:/var/www/html/wp-content/uploads
 ...
#top level
volumes:
    plugins:
    themes:
    uploads:

This compose file results in the following structure inside the container:

drwxr-xr-x. 3 www-data www-data   55 Aug  8 21:32 plugins
drwxr-xr-x. 5 www-data www-data   94 Aug  8 21:32 themes
drwxr-xr-x. 2 root     root        6 Aug 27 18:35 uploads

Which is of course the error already mentioned in #436 .

All 3 volumes were freshly created and were totally empty prior to container creation.

---

WORKAROUND

Instead of using the wp image directly, I use this Dockerfile and ensure the folder exists:

FROM wordpress:php8.0-apache
USER www-data
RUN mkdir -p /var/www/html/wp-content/uploads

After using the resulting image with my docker compose, everything works as expected. Do I misunderstand something, or is this PR not working?

[CyberDomovoy]

Actually, imho using root as default user is wrong, a user dedicated to the wordpress "application" (apache, php, whatever the wordpress part of the image needs) should be created, the image should be configured to fit that user (apache privilege drop, directories ownership...), and that user name/uid/gid should be documented (so that people can eventually map it on the host to manage ownership of the mounted volumes).

Using root and 777, no matter if it's in a containerized environment, is, imho, something to avoid at all cost.

Edit: this could be summarized as: the wordpress image should include a USER directive no matter what, for now it does it only for the cli.

[MorgusLethe]

@CyberDomovoy I understand your point but for this specific context/issue I don't believe your comment is relevant and may confuse readers... The fix for this is just to make sure the uploads directory exists in the image, owned by www-data with 755, like everything else in that dir.