Audit container configs for permissions management

[MoralCode]

Was just struggling to test #3337 because of issues mounting my augur.json and logs directories into the container environment (podman) for testing. While this was an issue on my somewhat uncommon setup, it made me realize:

podman and docker have fundamentally different viewpoints when it comes to permissions and security. Docker's rootful model generally defaults to running as root and passing through mounted directories with the same permissions (uid, gid, etc) as they exist on the host machine. In other words it's a fundamentally trusting environment.

Podman on the other hand, doesn't trust things by default, and instead runs containers in userspace, mapping the users in the container to high uid numbers on the host.

As more and more people are going to want to customize their configs with the augur.json file starting in this release, especially with all the new config options, It may be worth stepping through that usecase in both podman and docker to ensure the permissions and security models of both are able to work as designed and we can either a) fix, or b) document the steps needed to mount a custom config on both container environments.

[MoralCode]

• Create a comprehensive Dockerfile that follows best practices for non-root user execution.

• Add a docker-compose.yml for easier container orchestration.

Please make sure you understand the existing setup first. We already have a set of dockerfiles (which generally are not the problem) and a docker-compose file. the problem is more with compatibility between docker and podman with how permissions are handled, which I think may need to be a documentation fix, but I'm not sure.

I'd be happy to chat about this in more detail over on the CHAOSS Slack in the #wg-augur-8knot channel if you'd like. I think this should definitely be discussed and planned out thoroughly before making any changes, especially wholesale replacements of anything.

[sudiptasarkar011]

Hi @MoralCode

I would like to tackle this. This "Rootful vs. Rootless" permission conflict is a common pain point when orchestrating containers across different environments.

I encountered similar volume-mounting constraints while designing the microservices orchestration for my Ageiy Backend Platform, specifically when moving between local Docker daemons and stricter CI/CD runners. The mismatch usually stems from Podman’s user namespace mapping (where uid 0 inside != uid 0 outside) and SELinux contexts.

My Proposed Plan:

Audit current Dockerfile: Check if we are enforcing a specific USER instruction and if the augur.json directory has the correct chown permissions during the build stage.

Podman Compatibility Verification: I will test the current build with Podman using the --userns=keep-id flag and the :Z (SELinux private) volume label, which often resolves the "permission denied" errors on mounted configs.

Implementation:

If a code fix is needed: I can adjust the entrypoint.sh to dynamically handle ownership of mounted volumes if they don't match the container user.

If a doc fix is sufficient: I will add a dedicated "Podman & Custom Configs" section to the deployment docs, detailing the exact flags needed for seamless mounting.

I have my local environment ready to test this on both engines. Could you assign this to me?

[MoralCode]

Most of the stuff you describe isnt happening at build time. Config files are not baked into the image, the user it runs as is probably set in the compose file.

I would love for there to be documentation on some of the changes that may need to be made for permissions to work under Podman And I'm happy to share my patches that I'm carrying locally to make that work. But I don't really see any ways that we can adapt our current Dockerfile to be compatible with both, given the growing feature drift between the two tools.

I'm also a little hesitant to suggest filing a PR because we have so many in the backlog currently, but I'm happy to discuss this here or on Slack. If you want to work on narrowing in on a solution