Check permissions of important files before starting the installer

[emmatyping]

This was prompted by https://self-hosted.getsentry.net/organizations/self-hosted/issues/235/?project=3&query=is%3Aunresolved&referrer=issue-stream, but I believe that we have seen this before with other errors. I think we should probably start collecting files we know we should check before running:

• enhance-image.sh should be executable
• install/*.sh should be executable
• make sure we can read config files

(Please comment or edit this comment with more things we should check for)

[gitbugr]

I've been experiencing this issue, so I thought I'd shed some light:

It seems like what's happening is files are being mounted into the containers with identical permissions, but with root:root ownership. In the case of the sentry container, for instance, the root user is not used to run sentry (as is good practice) - however this renders those required files inaccessible.

This means, the only way to have them accessible inside the containers is with o+rx permissions on the host. Which would itself be an security issue.

I'm not sure what is the best course of action - this appears to be a common issue with Linux.

One could just change the ownership of the files on the host to the uid/gid of each given user of the sentry containers, though as those users wouldn't exist in the host's /etc/passwd file, you would need to find them out, as well as which files they need access to, which is itself a pain.

There are some proposed solutions in this blogpost, such as matching uid/gid between the host and container, or running the docker container in privileged mode and using BindFS to get around the permissions. https://www.joyfulbikeshedding.com/blog/2021-03-15-docker-and-the-host-filesystem-owner-matching-problem.html

Alternatively, could mount files using something like mutagen, which allows you to set ownership/permissions. It works by having a regular volume (rather than bind mount) and syncing between the host and the container, keeping them separate: https://mutagen.io/documentation/synchronization/permissions

[emmatyping]

files are being mounted into the containers with identical permissions, but with root:root ownership

Are you perhaps running things with sudo docker compose? That might cause docker to mount things as root.

[gitbugr]

@ethanhs I was though I had tried without previously. I've just tested again and it's still the case.

Steps taken;

1. Added my user to the docker group and restarted my shell.
2. docker compose down 'd
3. docker compose up -d 'd
4. Opened a shell in the container docker compose exec -it web sh
5. Jumped into sentry dir cd /usr/src/sentry
6. List files w/ perms: ls -la

# cd /usr/src/sentry
# ls -la
total 48
drwxr-xr-x 2 root root 4096 Dec 12 14:36 .
drwxr-xr-x 1 root root 4096 Dec 12 14:36 ..
-rwxr-xr-x 1 root root  424 Dec 12 14:33 Dockerfile
-rwxr-xr-x 1 root root 3877 Dec 12 14:33 config.example.yml
-rwxr-xr-x 1 root root 3915 Dec 12 14:36 config.yml
-rwxr-xr-x 1 root root  283 Dec 12 14:33 enhance-image.example.sh
-rwxr-xr-x 1 root root  329 Dec 12 14:33 entrypoint.sh
-rwxr-xr-x 1 root root  137 Dec 12 14:33 requirements.example.txt
-rwxr-xr-x 1 root root 7903 Dec 12 14:33 sentry.conf.example.py
-rwxr-xr-x 1 root root 7903 Dec 12 14:36 sentry.conf.py

o+rx is set because I've been testing with insecure perms on host for the time being, we can't run this in production as-is.

Setting perms on files via host to o-rx and restarting the container results in an access denied error.

For sake of transparency, I'm running this on a Ubuntu 22.04.1 LTS host

Also the files are owned by my user/group on the host.