Re: Thoughts on pg_hba.conf rejection

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>, Aidan Van Dyk <aidan@highrise.ca>, Bruce Momjian <bruce@momjian.us>, Joshua Tolley <eggyknap@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2010-04-15T00:19:45Z
Lists: pgsql-hackers
I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 14, 2010 at 4:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
>>> I think it sort of just died. I'm in favour of making sure we don't
>>> give out any extra information, so if the objection to the message is
>>> simply that "no pg_hba.conf entry" is "counterfactual" when there is an
>>> entry rejecting it, how about:
>>>  "No pg_hba.conf authorizing entry"
>>> 
>>> That's no longer counter-factual, and works for both no entry, and a
>>> rejecting entry...

>> That works for me.

> It needs copy-editing.  Maybe
> 	no pg_hba.conf entry allows access for host ... user ...

Actually, on reflection, I'm not sure that these suggestions really do
anything for the "counter-factual" complaint.  The case where you'd
normally use an explicit REJECT entry is where you're REJECTing some
limited case in an entry that is before a wider-scope entry that would
accept it.  So it doesn't seem entirely accurate to say that there is no
pg_hba.conf entry that would accept the connection.  There is one but
it's not the one we chose.

I'm thinking there isn't anything much we can do here without using a
different message wording for a match to a REJECT entry.  So it's a
straight-up tradeoff of possible security information leakage against
whether a different wording is really helpful to the admin.  Both of
those seem like fairly marginal concerns, really, so I'm having a hard
time deciding which one ought to win.  But given that nobody complained
before this, is it worth changing?

			regards, tom lane