From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | mail(at)goessmann(dot)io |
Subject: | BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed |
Date: | 2020-10-03 19:32:58 |
Message-ID: | 16652-58dd6028047058a6@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 16652
Logged by: Christoph Gößmann
Email address: mail(at)goessmann(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-10-03 20:02:24 | Re: BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed |
Previous Message | Naveen Kumar | 2020-10-03 17:04:27 | Adding partitions to the existing table in PostgreSQL |