Re: [PG19-3 PATCH] Don't ignore passfile

Great to see some consensus on the warning message at least.

I get that this is a niche issue and that it may not be a priority to make
a medium-sized change as changing from a warning to an error would be.
Regarding demand: Keep in mind that basically nobody will create an account
and join a mailing list to report a minor UX issue.

> As I recall, at the time this code was added, it was not at all
> unusual for systems to be set up with all users being members of
> a group named "users" or so, and even for that to be the default
> group for new files, so that granting group read was not a lot
> tighter than granting world read.
Does this include files created by root?
The usual way (again, same as SSH) is to only allow group permissions if
the file is owned by root.
This ensures that using group permissions was an intentional choice and not
an accident.
As mentioned before, Postgres is already doing this check for other files
(see: /src/interfaces/libpq/fe-secure-openssl.c:1269)
"private key file \"%s\" has group or world access; file must have
permissions u=rw (0600) or less if owned by the current user, or
permissions u=rw,g=r (0640) or less if owned by root"

> [...], so that idea that we can force "safe" permissions is a little bit
laughable.
Users can always store the password insecurely. Alerting about
easy-to-detect issues is nice of course, but there's no protection against
things like:
# Provide connection info
cat > start.sh <<EOF
export PGPASSWORD="mypass"
./actual-postgres-app
EOF
chmod 777 start.sh # Make my script executable

Might be a ridiculous example, but maybe more likely than somebody running
Postgres on macOS using a mis-secured passfile (owned by root with group
staff or similar) with multiple users.

In my very particular case the restrictions imposed force me to put the
password in the configuration file somehow (plain, via templating script,
helm --set, etc.) as I cannot mount with permissions below 0440 (k8s
fsGroup) and cannot use environment variables (particular helm chart).
Using passfile with group permissions would be a more straight forward way
to set the password securely here.
For reference: homeserverConfig.database.args.password in
https://github.com/remram44/matrix-helm/blob/master/charts/matrix/values.yaml
I'm not looking to resolve this particular case (I already use helm --set),
just mentioning it as an example use-case for anyone interested.

Yes this is a niche issue, as most people using containers use PGPASSWORD
and most people not using containers don't care about groups on the
passfile.
It is possible to work around it and the barrier to reporting issues to
Postgres is higher then "thumps up on GitHub issue" as with many other open
source projects, so not many people will complain.