Make APP_ROOT chown optional

[bircher]

The idea is to allow avoiding the chown in the setup script.

I use user 1000 on my host and I pass that to the docker-compose exec (as in docker-compose exec --user 1000 php ./vendor/bin/drush --root="/var/www/html/web" (I use the composer project template)) now I need to make the app root chown 777 so that I can do anything. But more importantly the user www-data should not have write access to the code but only to sites/default/files. To quote the first paragraph of https://www.drupal.org/node/244924:

The server file system should be configured so that the web server (e.g. Apache) does not have permission to edit or write the files which it then executes. That is, all of your files should be 'read only' for the Apache process, and owned with write permissions by a separate user.

for me the most convenient would be if that user would have uid 1000, but if it just doesn't exist it is fine anyway since docker-compose can execute things with a specific uid even if the user was not explicitly defined. So the best would be to make it optional so that in my docker-compose.yml I can set an environment variable and be happy.

My current workaround is to mount all the files into /var/www/html/project.

I have not tested the script change (and I am not proficient with bash and do all scripting in python) so maybe it can be improved.

[csandanov]

But more importantly the user www-data should not have write access to the code but only to sites/default/files.

We change the owner only of the root volume only (/var/www/html), it's not recursive. We don't change ownership of the codebase files and we should not – it may take a looot of time depending on the codebase size.

[csandanov]

What we probably can and should do is change the user of fpm and nginx processes and keep only the group so they would not have write permissions.

[bircher]

Yes the permission change is not recursive. But because I (and the default in docker4drupal) mount the project root to that it changes the permission on the host folder too.

    volumes:
        - ./:/var/www/html

So for now I just live with the fact that my project folder is owned by a user that doesn't exist on my host and set the permission to 777 so that I can change the files in the project. I don't know why the permissions are set in the first place but it would be convenient to at least being able to turn it off.

[bircher]

oh, another idea would be to make the uid and gid configurable, then the chmod would not have any effect and I would not even have to specify as which user to run drush etc...

Maybe (or in addition) that would be very useful too.

[csandanov]

The server file system should be configured so that the web server (e.g. Apache) does not have permission to edit or write the files which it then executes. That is, all of your files should be 'read only' for the Apache process, and owned with write permissions by a separate user.

We now run fpm from php-fpm user (uid 1000), www-data is still the default user. Available since stability tag 3.5.0

oh, another idea would be to make the uid and gid configurable

Even if we make uid/gid configurable you'll have to rebuild the image, and if you're going to build an image, I suppose it would be easier to just build a new image on top of wodby/php and manually change UIDs (recreate users). Besides uid 82 is alpine de-facto standard for www-data user and uid 1000 is a de-facto standard for PID 1 in docker images.

Thank you for your input.

[csandanov]

See https://github.com/wodby/php/issues/22