| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Thoughts on pg_hba.conf rejection |
| Date: | 2010-04-19 20:30:21 |
| Message-ID: | 5856.1271709021@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Point of note on giving information to the bad guys: if a
> should-be-rejected connection request attempts to connect to a
> non-existent database, we say "database does not exist".
Yeah. This was an acknowledged shortcoming of the changes to eliminate
flat-file storage of authentication information --- as of 9.0, it's
necessary to connect to some database in order to proceed with auth
checking. We discussed it at the time and agreed it was an acceptable
loss.
The only way I can think of to improve that without going back to flat
files would be to develop a way for backends to switch databases after
initial startup, so that auth could be done in a predetermined database
(say, "postgres") before switching to the requested DB. This has enough
potential gotchas, in regards to catalog caching for instance, that I'm
not eager to go there.
Alternatively we could lie, and produce an auth failure message of some
sort rather than admitting the DB doesn't exist. But that seems like
it's going to create enough confusion to not be acceptable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-04-19 20:45:07 | Re: Thoughts on pg_hba.conf rejection |
| Previous Message | Tom Lane | 2010-04-19 20:18:38 | Re: Standalone backends run StartupXLOG in an incorrect environment |