Don't run docker containers as root

[jeremyestein]

Fixes #234. Waiting for testing on GAE before merging.

Note the addition of two new variables PIXL_USER_UID and PIXL_USER_GID

Firstly merge all the Dockerfiles for images that we control (imaging, export, hasher) to make this process easier.

Run all our python containers as the user/group pixl, which we create as part of the build process, using the UID/GID as specified in the config.

Export API mounts export dir read-only as it doesn't need to write any more.

Document how the host must be set up for this to work.

Do same for orthanc images.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.16%. Comparing base (cbf9e3b) to head (242aacf).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #400 +/- ## ======================================= Coverage 81.16% 81.16% ======================================= Files 78 78 Lines 3191 3191 ======================================= Hits 2590 2590 Misses 601 601 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[jeremyestein]

In writing the docs, I have come up with what I think is a problem, that will likely need a user/group adding to the GAE to fix.

---

Imagine you are a user on the GAE with username fred, primary group fred, and supplementary group docker.

When you run the CLI, it will run as fred:fred, and normally any files it creates would also have this ownership. (ACLs defined in /gae will affect this however, so the files may have a different group ownership, such as fred:docker)

There is a problem here in that the export API will likely be running as some other user/group, so it will not be able to read the files.

Options for fixing:

• The CLI (or an ACL on the exports dir) makes the files world readable. Not ideal from a security pov.
• Relying on the existing ACL for /gae which gives files group ownership of docker, we run the Export API as the docker group, thus giving it read access to these files. However, this is very similar to running the container as root, which is what this whole thing is trying to avoid.
• Create a new group (pixl) on the GAE and add all pixl devs to it. Set an ACL on the exports dir that sets group ownership for all created files as pixl. Then we could set its GID in the env file so that the container runs as group pixl.
• Always build and run the containers as the same user that is running the CLI. You set the build vars PIXL_USER_[UG]ID to the numerical value of fred:fred. PIXL runs as you. When you run CLI, the files are owned by fred:docker, so export api can read them fine. This lacks flexibility as we should all be able to run PIXL.
• Refactor so the CLI doesn't write any files. Then it's just Export API doing the reading and writing, and it can use a docker volume and avoid all permissions problems. Export API would need read access to the OMOP extracts (does that loop back to the existing problem?)

[jeremyestein]

This change can't go in until the pixl user and group have been created on the GAE, and the pixl dev users added to the group.

[dram1964]

This change can't go in until the pixl user and group have been created on the GAE, and the pixl dev users added to the group.

Hi @jeremyestein, I've added PIXL user and group to GAE05 - and added you to the group. Let me know how that works for you.

[stefpiatek]

Had to run using docker group GID because all mounts will preserve the group that wrote them.

Added as a secondary group and as its just a file permission I think that'd be fine.

Example of permission error for a directory:

pixl_dev-orthanc-anon-1  | E0614 14:32:09.175160             MAIN main.cpp:2123] Uncaught exception, stopping now: [boost::filesystem::directory_iterator::construct: Permission denied: "/run/secrets"]