Thoughts on pg_hba.conf rejection
in [PgSql]
|
From: Tom Lane on 20 Apr 2010 14:24 I wrote: > ... So we could solve both this and > the original complaint in the thread if we can arrange for all > authentication to be done on the basis of shared-catalog access under > rules similar to what the AV launcher does with pg_database. At a > minimum that will require marking the pg_auth catalogs as > BKI_SCHEMA_MACRO, but that's far less painful than it used to be. > I don't recall what other consequences there are, but will go looking. I've been looking at this and it seems do-able, though I don't have working code yet. Downsides appear to be: 1. We'd have to force an initdb because of a couple of small catalog changes. This doesn't seem like a showstopper at this phase of the release cycle, but it's slightly annoying. pg_migrator could be used if anyone's really in need of it. 2. We don't have infrastructure that would allow access to out-of-line toasted fields during startup. Rather than try to add such, I propose removing pg_authid's toast table, with the consequence that rolpassword cannot be long enough to require out-of-line storage (note it could still be compressed in-line). I cannot imagine any real situation where this would be an issue --- does anyone else? (BTW, I'm fairly sure that we couldn't support an out-of-line rolpassword in the past anyway, because of restrictions in the old flatfiles code.) 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into relcache, because relcache.c isn't prepared to cope otherwise. I doubt this would affect performance in any material way, but it would eat a few more kbytes of storage per backend. None of these seem like reasons not to do it. Objections? regards, tom lane -- 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 20 Apr 2010 15:30 Tom Lane escribi�: > 1. We'd have to force an initdb because of a couple of small catalog > changes. This doesn't seem like a showstopper at this phase of the > release cycle, but it's slightly annoying. pg_migrator could be used > if anyone's really in need of it. check > 2. We don't have infrastructure that would allow access to out-of-line > toasted fields during startup. Rather than try to add such, I propose > removing pg_authid's toast table, with the consequence that rolpassword > cannot be long enough to require out-of-line storage (note it could > still be compressed in-line). I cannot imagine any real situation where > this would be an issue --- does anyone else? (BTW, I'm fairly sure that > we couldn't support an out-of-line rolpassword in the past anyway, > because of restrictions in the old flatfiles code.) In the past rolconfig could have been a problem too, but fortunately we got that moved out. I really doubt that a password of "only" about 2kB compressed is going to be a limitation to anyone on this planet. (Hmm, isn't it really 8kB in row length that's the hard limit?) This could perhaps be an issue if we were to store an SSL certificate in rolpassword or something like that, but I don't think we support that. > 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into > relcache, because relcache.c isn't prepared to cope otherwise. I doubt > this would affect performance in any material way, but it would eat a > few more kbytes of storage per backend. This doesn't limit that VACUUM FULL or other commands are applied to those catalogs, right? > None of these seem like reasons not to do it. Objections? None here. -- 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
From: Robert Haas on 20 Apr 2010 15:35 On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 1. We'd have to force an initdb because of a couple of small catalog > changes. This doesn't seem like a showstopper at this phase of the > release cycle, but it's slightly annoying. pg_migrator could be used > if anyone's really in need of it. Fine. > 2. We don't have infrastructure that would allow access to out-of-line > toasted fields during startup. Rather than try to add such, I propose > removing pg_authid's toast table, with the consequence that rolpassword > cannot be long enough to require out-of-line storage (note it could > still be compressed in-line). I cannot imagine any real situation where > this would be an issue --- does anyone else? (BTW, I'm fairly sure that > we couldn't support an out-of-line rolpassword in the past anyway, > because of restrictions in the old flatfiles code.) I think that's OK. > 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into > relcache, because relcache.c isn't prepared to cope otherwise. I doubt > this would affect performance in any material way, but it would eat a > few more kbytes of storage per backend. Hmm, I'm not sure I understand why this is necessary or what our other options are. ....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: Simon Riggs on 19 Apr 2010 15:10 On Thu, 2010-04-15 at 09:44 -0400, Tom Lane wrote: > Maybe uaImplicitReject for the end-of-file case would be > the most readable way. uaImplicitReject capability added. We're now free to bikeshed on exact wording. After much heavy thinking, message is "pg_hba.conf rejects..." with no hint (yet?). 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". If db does exist we say "pg_hba.conf rejects...". To me that looks like giving info away... if an IP address range is rejected always then telling them whether or not a particular database name exists seems like something I would not wish to expose. -- 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: Tom Lane on 19 Apr 2010 16:30
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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |