fix(infra): grant audit roles to current_user, not hardcoded portal #60
Reference in New Issue
Block a user
Delete Branch "fix/infra/init-sql-current-user"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The bootstrap SQL ended with:
— hard-coded
portal. The compose file and.env.exampleboth documentPOSTGRES_USERas overridable; any contributor who changed it hit:Replace with
current_user, which resolves at execution time to whoever is running the init SQL — i.e. the superuser Postgres just created fromPOSTGRES_USER, whatever its name.Recovery for anyone hit by the bug
The half-failed init left the postgres-data volume in a partially-initialised state. To reset:
Test plan
docker compose psshows postgres healthy.psql postgres://<user>:<pwd>@localhost:5432/portal_dev -c "\du"lists the fouraudit_*roles, and your superuser is "Member of: {audit_owner, audit_writer, audit_reader, audit_archiver}".psql ... -c "\dn"shows theauditschema.POSTGRES_USERvalue (setPOSTGRES_USER=apf_portalin.env, wipe volume, re-up) — init still succeeds.The bootstrap SQL ended with: GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO portal; which assumed POSTGRES_USER is `portal`. The compose file (and the .env.example) document POSTGRES_USER as overridable — anyone who changed it to something else (e.g. `apf_portal`) hit: ERROR: role "portal" does not exist psql: .../01-init.sql:48: ERROR: role "portal" does not exist `current_user` resolves at script execution to whoever is running the init SQL — that is, the superuser Postgres just created from POSTGRES_USER, regardless of its name. Use it instead of hard-coding `portal`. Recovery for anyone hit by the original bug: cd infra/local docker compose -f dev.compose.yml down -v # wipes the # half-initialised # postgres-data volume docker compose -f dev.compose.yml up -d # bootstrap re-runs # cleanly