Thoughts on pg_hba.conf rejection
in [PgSql]
|
From: Simon Riggs on 19 Apr 2010 16:45 On Mon, 2010-04-19 at 16:30 -0400, Tom Lane wrote: > Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 19 Apr 2010 16:59 On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Simon Riggs <simon(a)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. 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. Would it be possible to set up a skeleton environment where we can access shared catalogs only and then decide on which database we're using later? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 19 Apr 2010 17:04 Robert Haas escribi�: > On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > 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. > > Would it be possible to set up a skeleton environment where we can > access shared catalogs only and then decide on which database we're > using later? Eh? We already do that ... In fact the autovac launcher is always connected to shared catalogs, without being connected to any one database in particular (cf. get_database_list) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 19 Apr 2010 17:08 On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Robert Haas escribió: >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> > 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. >> >> Would it be possible to set up a skeleton environment where we can >> access shared catalogs only and then decide on which database we're >> using later? > > Eh? We already do that ... In fact the autovac launcher is always > connected to shared catalogs, without being connected to any one > database in particular (cf. get_database_list) Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to connect to some database in order to proceed with auth checking". Why is that necessary, if we can access shared catalogs without it? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 19 Apr 2010 17:12
Robert Haas escribi�: > On Mon, Apr 19, 2010 at 5:04 PM, Alvaro Herrera > <alvherre(a)commandprompt.com> wrote: > > Robert Haas escribi�: > >> On Mon, Apr 19, 2010 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > > >> > 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. > >> > >> Would it be possible to set up a skeleton environment where we can > >> access shared catalogs only and then decide on which database we're > >> using later? > > > > Eh? �We already do that ... In fact the autovac launcher is always > > connected to shared catalogs, without being connected to any one > > database in particular (cf. get_database_list) > > Oh. Then I'm confused. Tom said: "as of 9.0, it's necessary to > connect to some database in order to proceed with auth checking". Why > is that necessary, if we can access shared catalogs without it? Hmm, yeah, why did he say that? Maybe the order of operations during startup is such that we only do auth checking after connecting to a database for some reason. Whatever it is, I don't think a badly worded error message is enough grounds for fooling with this at this time of release process, though. To be discussed for 9.1? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |