Do not run containers as root and do not create root owned files

[jeremyestein]

Definition of Done / Acceptance Criteria

• Containers are no longer run as root.
• Files created by containers on mounted file systems are no longer owned by root, and thus they are readable/writable/deletable by a normal user.

The criteria above will both be fixed if the container no longer runs as root. If for some reason you only implement a fix for the file permissions issue (eg. by chowning the files after creating them), this issue should be split so the running as root issue is not lost.

Testing

System test should check which user each container is running as after bringing them up. Note that running on a non-linux host will falsely cause such a test to pass, as the special docker linux kernel on these platforms doesn't map container root to host root in the first place.

Any test that checks the presence and contents of an output file should also check the file's ownership. For an example, see check_radiology_parquet.py where these tests exist but have been temporarily demoted to logging only.

Documentation

Depends on implementation as to whether user will have to do anything different because of this (eg. set an environment var)

Dependencies

Some possible solutions would need a reconfiguration of the GAE via Atos, which could take some time.

Details and Comments

Rationale

• Running as root is a security hazard. If one of the services gets compromised then the attacker can do more bad stuff to the GAE than they would otherwise.
• Files owned by root cannot be deleted/moved/etc by a normal user (or indeed a system test).

Possible implementations

• Run docker daemon in "rootless" mode - will require some changes via Atos?
• User namespaces (userns_mode ) - also requires admin?
• Set the user directly with the user property of the docker compose service spec.

Someone may have to play around with a Docker install on Linux to see what works so we know what (if anything) we want to ask Atos for.

[milanmlft]

Yeahhh, I encountered this issue as well when trying to tear down the export directories created by tests for #226, which ran fine locally but then ran into errors on the GHA because indeed the Docker volumes were root-owned and so any files created there could not be deleted... I ended up working around this by ignoring errors from shutil.rmtree(), meaning the files won't actually get deleted on the GHA runner 🤷

Turns out though that this is a longstanding issue with Docker-compose named volumes. There are some workarounds but none of them are trivial.
Just running the containers as non-root, for example, does not seem to resolve the issue, though haven't tried this myself.

[stefpiatek]

Part of wider work on best practices on GAEs.

• secret managment
• failover
• logging and monitoring

[dram1964]

as per #239 this is an issue that although not solved by, can still be monitored by 'docker scout'. Am investigating this to see if it is a viable approach.

[dram1964]

I've created an SOP for using Docker on the FlowEHR-Operations-Manual repo and will link to SLAB once it's been through it's PR review

[dram1964]

Check for privileged running with: docker container inspect --format '{{.Config.User}}' $container_id. Blank output suggests running as root.

[stefpiatek]

Currently have: guidance for GAE running, collect auditing data

• Should create another issue to track using the audit data - @dram1964

[skeating]

@jeremyestein Moving this to in progress, could you add additional tickets for the ones you haven't done. Thank you