Thoughts on pg_hba.conf rejection
in [PgSql]
|
From: Tom Lane on 20 Apr 2010 10:05 Robert Haas <robertmhaas(a)gmail.com> writes: > http://blog.metasploit.com/2010/02/postgres-fingerprinting.html > Assuming the situation really is as described here, I am wondering if > we should suppress the F, L, and R output in this and similar cases > and back-patch it all the way back. This seems like it is entirely > too helpful. [ yawn.. ] I'm unimpressed: should we also ensure that neither ASCII nor translated texts of authentication failure messages ever change? IIRC, you were lobbying *for* such a change only a day or two ago. 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: Tom Lane on 20 Apr 2010 10:19 I wrote: > Actually, while I'm looking at that code, a more immediate TODO is > "fix walsender". Somebody has inserted an absolutely flight-of-fantasy > code path into InitPostgres. (Hint: template1 can be dropped. > ESPECIALLY when you're deliberately not taking any lock on it.) Now that I look more closely, it seems what we have actually got there is an incorrect attempt to solve the problem of authenticating without selecting any particular database. 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. 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: Tom Lane on 20 Apr 2010 17:02 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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. relcache.c assumes that "critical" relations (those for which we have hard-wired descriptors in schemapg.h) are always nailed-in-cache. In the general case this is necessary because we'd not be able to rebuild the cache entry if it got discarded; eg, without a pg_class entry you're dead in the water. It's possible we could decouple these attributes; for instance develop a notion of being nailed only until authentication finishes, or something like that. I'm not thinking it's worth it though. 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: Tom Lane on 20 Apr 2010 17:43 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Tom Lane escribió: >> 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?) Actually, rolconfig would be OK because it doesn't have to be accessed until after we've completed authentication. However there's no really nice way to ensure that rolpassword doesn't get toasted if another column can be. I suppose we could have initdb force its attstorage to PLAIN or some such. > 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. Nope, not that I know of. Anyway we could solve the problem if it ever came up --- I don't think there's anything insurmountable about accessing shared toast tables here, we'd just need some support to allow them to be nailed-in-cache. >> 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? Nope, it's no different from pg_database. Attached is a draft patch --- it looks pretty reasonable, but I've not tested the impact on walsender yet. regards, tom lane
From: Robert Haas on 20 Apr 2010 17:51
On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 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. > > relcache.c assumes that "critical" relations (those for which we have > hard-wired descriptors in schemapg.h) are always nailed-in-cache. In > the general case this is necessary because we'd not be able to rebuild > the cache entry if it got discarded; eg, without a pg_class entry you're > dead in the water. It's possible we could decouple these attributes; > for instance develop a notion of being nailed only until authentication > finishes, or something like that. I'm not thinking it's worth it > though. Well that just begs the question - why do we need a hard-wired descriptor? Presumably we should only need to hard-wired descriptors for the relations are used by the relcache code itself to build more descriptors - so clearly pg_cache and pg_attribute, but beyond that I don't get it. In particular, I can't see any reason why we couldn't just build the descriptor for pg_authid etc. by scanning pg_class and pg_attribute. ....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 |