supabase
Setting a different username on the image fails
Bug report
- [x] I confirm this is a bug with Supabase, not with my own application.
- [x] I confirm I have searched the Docs, GitHub Discussions, and Discord.
Describe the bug
When a different username is passed using POSTGRES_USER the container will exit as the user doesn't exist:
docker run \
-e POSTGRES_PASSWORD=custom \
-e POSTGRES_USER=custom \
-e POSTGRES_DB=custom \
supabase/postgres
...
server started
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "custom"
[local] 2023-06-26 10:09:42.844 UTC [68] custom@postgres LOG: provided user name (custom) and authenticated user name (postgres) do not match
[local] 2023-06-26 10:09:42.844 UTC [68] custom@postgres FATAL: Peer authentication failed for user "custom"
[local] 2023-06-26 10:09:42.844 UTC [68] custom@postgres DETAIL: Connection matched pg_hba.conf line 83: "local all all peer"
Error: exit status 2
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
docker run \
-e POSTGRES_PASSWORD=custom \
-e POSTGRES_USER=custom \
-e POSTGRES_DB=custom \
supabase/postgres
Expected behavior
Database & user are created with passed environment variables
Screenshots
NA
System information
NA
Additional context
NA
Main difference that "causes" this is that the base image doesn't use peer authentication for local executed commands, but rather trusts anything that comes from the unix domain.
Possible fix would be to add something in the entrypoint that appends the postgres → $POSTGRES_USER mapping to pg_ident if $POSTGRES_USER != postgres. I'd gladly write this and do a PR but not sure if opinions differ on that approach.
At this point we don't support configurable roles using the docker env vars
Supabase comes with pre-installed tables like auth.users, storage.objects etc with permissions created by migrations that assume the user's role is named postgres and a handful of other roles used by specific services e.g. supabase_auth_admin.
You can still create custom roles via the SQL layer/a migration as needed
