Thread: BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed
BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed
From
PG Bug reporting form
Date:
The following bug has been logged on the website: Bug reference: 16652 Logged by: Christoph Gößmann Email address: mail@goessmann.io PostgreSQL version: 11.4 Operating system: CentOS Linux 7 Description: I recently edited the contents of pg_hba.conf and made a mistake there. I chose method "peer" for a "host" connection type. When reloading the configuration with via "SELECT pg_reload_conf();" the log rightfully states the following: LOG: peer authentication is only supported on local sockets CONTEXT: line 97 of configuration file "/cluster/work/lawecon/Work/goessmann/pg_server/pg_data/pg_hba.conf" LOG: pg_hba.conf was not reloaded But: The command "SELECT pg_reload_conf();" returns TRUE, letting the admin believe that the new configuration is active and that potentially new IP rejects or other security modifications now are active (if performed at the same opportunity) -- especially since users typically do not check the logs regularly if there is no problem they are aware of. Eventually, the misconfiguration will become evident when the database cluster is restarted, but in many configurations this can take a long time -- potentially leaving the database cluster exposed while anticipating that some newly established security rules are active.
Re: BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed
From
"David G. Johnston"
Date:
On Saturday, October 3, 2020, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 16652
Logged by: Christoph Gößmann
Email address: mail@goessmann.io
PostgreSQL version: 11.4
Operating system: CentOS Linux 7
Description:
The command "SELECT pg_reload_conf();" returns TRUE, letting the admin
believe that the new configuration is active and that potentially new IP
rejects or other security modifications now are active (if performed at the
same opportunity) -- especially since users typically do not check the logs
regularly if there is no problem they are aware of.
The documentation could maybe better describe what is considered successful but these functions state they signal other, multiple, backends. Signaling is unidirectional so practically speaking all the function knows is that it successfully sent the signals, not that those signals were received and/or successfully processed; information it doesn’t readily have.
David J.