Thread: BUG #12788: host / peer auth works after pg_ctl reload, then blocks server startup

The following bug has been logged on the website:

Bug reference:      12788
Logged by:          Daniel Howard
Email address:      dannyman@toldme.com
PostgreSQL version: 9.3.2
Operating system:   CentOS
Description:

Hello,

I naively added a line like this to pg_hba.conf:

host   all             postgres        x.x.x.x/32           peer

I ran pg_ctl reload.

I was then able to connect from x.x.x.x to do backups.

I then restarted the server, and it failed, with this error:

LOG:  peer authentication is only supported on local sockets

I removed the above line from pg_hba.conf and server completed startup.  I
can no longer connect from host x.x.x.x.

I can see why pg_ctl reload might gloss over a config issue instead of
bringing down the server, but that the invalid auth configuration then works
strokes me as a bug.

Thanks,
-danny

dannyman@toldme.com writes:
> I naively added a line like this to pg_hba.conf:

> host   all             postgres        x.x.x.x/32           peer

> I ran pg_ctl reload.

"pg_ctl reload" unfortunately has no way to detect whether the reload
succeeded.  Had you checked in the postmaster log you'd likely have
found some bleating to the effect that the reload didn't take.

> I was then able to connect from x.x.x.x to do backups.

If so, it must have been due to some previously existing entry.

> I then restarted the server, and it failed, with this error:
> LOG:  peer authentication is only supported on local sockets

Yup ...

> I can see why pg_ctl reload might gloss over a config issue instead of
> bringing down the server, but that the invalid auth configuration then works
> strokes me as a bug.

It didn't "work".  Making the postmaster keep running despite the
attempt to load a bad file has been generally agreed to be the
best thing, but it does mean that if you don't pay attention to
the effects of a reload, you can shoot yourself in the foot like
this :-(.

AFAICS the only thing we could do to make this significantly safer
would be to restrict use of "pg_ctl reload" to scenarios wherein
pg_ctl could determine whether the postmaster had reloaded its
config without any complaints.  Unfortunately, that would be a
pretty draconian restriction, so there's no free lunch here.

            regards, tom lane