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.yamlI'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.
