Possible permission error with opening /opt/healthchecks/docker/uwsgi.ini after building image and launching the container

[Klionheart]

On some (particularly security-conscious?) machines, after the repository is cloned, files and directories in the local copy can end up with 700/600 permissions. In my case it was a Synology system with "0077" umask forcing the permissions to be like this:

ll healthchecks/
total 268
drwx------ 1 root root 264 Dec 26 11:51 .
drwx------ 1 root root 24 Dec 26 11:50 ..
-rw------- 1 root root 24634 Dec 26 11:51 CHANGELOG.md
-rw------- 1 root root 2462 Dec 26 11:51 CONTRIBUTING.md
drwx------ 1 root root 116 Dec 26 11:52 docker
drwx------ 1 root root 138 Dec 26 11:51 .git
drwx------ 1 root root 40 Dec 26 11:51 .github
-rw------- 1 root root 81 Dec 26 11:51 .gitignore
drwx------ 1 root root 190 Dec 26 11:51 hc
-rw------- 1 root root 1507 Dec 26 11:51 LICENSE
drwx------ 1 root root 16 Dec 26 11:51 locale
-rwx------ 1 root root 468 Dec 26 11:51 manage.py
-rw------- 1 root root 20283 Dec 26 11:51 README.md
-rw------- 1 root root 175 Dec 26 11:51 requirements.txt
-rw------- 1 root root 401408 Dec 26 11:51 search.db
drwx------ 1 root root 26 Dec 26 11:51 static
drwx------ 1 root root 82 Dec 26 11:51 stuff
drwx------ 1 root root 214 Dec 26 11:51 templates

As a consequence, when you build a docker image on such a system, the container directory "/opt/healthchecks/docker/" ends up with the same permissions, meaning it is not accessible by the "hs" user in the container.
So the startup command "uwsgi /opt/healthchecks/docker/uwsgi.ini" fails and the container never starts.

For a solution, the owner of the directory in the container can simply be changed to the "hs" user in the Dockerfile, for example:

RUN
rm -f /opt/healthchecks/hc/local_settings.py && \
DEBUG=False SECRET_KEY=build-key ./manage.py collectstatic --noinput && \
DEBUG=False SECRET_KEY=build-key ./manage.py compress && \
chown -R hc /opt/healthchecks

I tried the above while building my own image and it seems to be ok. The container works and the file system looks like this:

hc@b7f3a717696d:/opt/healthchecks$ ls -l
total 488
-rw------- 1 hc root 24634 Dec 26 10:51 CHANGELOG.md
-rw------- 1 hc root 2462 Dec 26 10:51 CONTRIBUTING.md
-rw------- 1 hc root 1507 Dec 26 10:51 LICENSE
-rw------- 1 hc root 20283 Dec 26 10:51 README.md
drwx------ 1 hc root 4096 Dec 26 10:52 docker
drwx------ 1 hc root 4096 Dec 26 10:52 hc
drwx------ 1 hc root 4096 Dec 26 10:51 locale
-rwx------ 1 hc root 468 Dec 26 10:51 manage.py
-rw------- 1 hc root 175 Dec 26 10:51 requirements.txt
-rw------- 1 hc root 401408 Dec 26 10:51 search.db
drwx------ 1 hc root 4096 Dec 26 10:51 static
drwxr-xr-x 8 hc root 4096 Dec 26 10:52 static-collected
drwx------ 1 hc root 4096 Dec 26 10:51 stuff
drwx------ 1 hc root 4096 Dec 26 10:51 templates

I don't believe there should be other issues with having "hc" own the healthchecks directory...in fact it does seems to make logical sense.
If you agree, the fix here should be fairly straightforward and might avoid some unexpected headaches in the future ;)

[cuu508]

Thank you for the report.

A problem I see with the proposed solution is, the hc user would now have write access to the files. It should only have read access.

[cuu508]

• Changing the owner (chown) would make files writable by the hc user, which is not good security-wise
• Changing file permissions (chmod) would be problematic, as the hc user needs read permission only for some files, and read+execute permission for others
• Perhaps a better way to fix this is to make sure git clone creates files with the correct permissions to start with. I've not tested this, but look into setting git's core.sharedRepository setting to all.