Обсуждение: 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

От
PG Bug reporting form
Дата:
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

От
"David G. Johnston"
Дата:
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.