Thoughts on pg_hba.conf rejection
in [PgSql]
|
From: Tom Lane on 19 Apr 2010 19:09 Simon Riggs <simon(a)2ndQuadrant.com> writes: > 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. Well, that's nice, but it's an awfully small subset of what the pg_hba.conf rules might contain. In particular you can't do anything that involves group membership checks without access to the catalogs; and I think a large fraction of installations that are exposed to untrustworthy connections will be using password auth for them, which means they still need to connect to the catalogs to get the password. Now it's possible that we could have a prefilter that rejects connections if they're coming from an IP address that cannot match *any* of the pg_hba.conf rules. Not sure how useful that would really be in practice though. It wouldn't do anything extra for people who keep their DB server behind a firewall. 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 19 Apr 2010 19:18 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Robert Haas escribi�: >> 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) Hmm. The AV launcher is only permitted to touch pg_database. At the time there were considerable advantages to that restriction, but subsequent changes (like getting rid of the need for manual maintenance of pg_attribute entries for bootstrap catalogs) might mean that it wouldn't be too painful to extend this capability to pg_authid etc. Could be worth thinking about. 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: Robert Haas on 19 Apr 2010 19:26 On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: >> Robert Haas escribió: >>> 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) > > Hmm. The AV launcher is only permitted to touch pg_database. > At the time there were considerable advantages to that restriction, > but subsequent changes (like getting rid of the need for manual > maintenance of pg_attribute entries for bootstrap catalogs) might > mean that it wouldn't be too painful to extend this capability to > pg_authid etc. Could be worth thinking about. Perhaps we should add a TODO. ....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: Tom Lane on 19 Apr 2010 20:11 Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Hmm. �The AV launcher is only permitted to touch pg_database. > Perhaps we should add a TODO. 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.) 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: Robert Haas on 19 Apr 2010 23:03
On Mon, Apr 19, 2010 at 8:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Mon, Apr 19, 2010 at 7:18 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Hmm. The AV launcher is only permitted to touch pg_database. > >> Perhaps we should add a TODO. > > 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.) Off-topic to that, but on-topic to the original topic of this thread, check out this link that Karen Padir just blogged about on planet.postgresql.org: 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. ....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 |