Re: Thoughts on pg_hba.conf rejection - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Thoughts on pg_hba.conf rejection
Date
Msg-id 1271709907.8305.20211.camel@ebony
Whole thread Raw
In response to Re: Thoughts on pg_hba.conf rejection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Thoughts on pg_hba.conf rejection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2010-04-19 at 16:30 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.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.  

With code as currently, yes, though I see that there is a way to do
this. 

Rules that have an "all" in the database field of the hba can be applied
prior to attempting to select the database, as long as the "all" rule is
above any database-specific rules. So its possible, we just need to
special case the code so we call it once before db is assigned for "all"
rules only and then again later, as is now, including 100% of rules. (I
say 100% to avoid using the word all in two contexts in same sentence).

> 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.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Thoughts on pg_hba.conf rejection
Next
From: Robert Haas
Date:
Subject: Re: Thoughts on pg_hba.conf rejection