Fix owner and group of $PGDATA at start

[markusheiden]

When mounting a volume to /var/lib/postgresql/data the owner (postgres) and group (postgres) set by the Dockerfile are "lost". Thus, if doing so, one currently needs an init container to fix that. This change avoids that.

[tianon]

See this section just a little bit lower than your change, which effectively does the same chown -R, but more efficiently (only down the chown for files/folders that actually need it) and only when we can be reasonably sure it might succeed (when the script starts as root and is responsible for stepping down to the postgres user itself):

https://github.com/docker-library/postgres/blob/cba2a05c03706daf5f9a66b93a447540b62df063/docker-entrypoint.sh#L56-L60

[markusheiden]

Sorry, I overlooked that.

But that code does not solve my problem. If I read that code right, it is active only if running the container as root (user 0) though the comment says the opposite (--user). But if running as the user postgres it most probably won't have the right to change the owner to postgres though.

My problem: When using a Kubernetes container with securityContext: runAsNonRoot: true, runAsGroup: 70, and runAsUser: 70, this code won't trigger. Postgres definitively does not start if I mount a volume to /var/lib/postgresql/data until I execute chown -R 70:70 /var/lib/postgresql/data via an init container.

Is there a way to avoid that init container?

Maybe I better opened an issue instead...

[tianon]

Unfortunately it is not possible to fix this without an init container in the scenario you've described - as you've noted, the chown will fail in any non-root case, which is why we qualify it with being root (and that if statement is what allows us to run with --user and allows your use case to function at all, even if not with the ideal permissions :sweat_smile:).

[markusheiden]

Thanks for taking the time to answer this. Sorry, for me wasting it. I will close this MR.