From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: host name support in pg_hba.conf |
Date: | 2010-08-10 15:08:28 |
Message-ID: | 419.1281452908@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
>> I was about to complain about that same thing. ISTM the logic ought
>> to be that you do a forward DNS lookup on the name presented in
>> pg_hba.conf, and if any of the returned IP addresses match the
>> connection's remote IP address, then you have a match. This business
>> with doing a reverse lookup is at least twice as expensive, far more
>> fragile, and it seems completely bogus from a security viewpoint.
> If you have hundreds on lines in pg_hba.conf, then you need to do
> hundreds of DNS lookups per connection attempt (*), and each of those
> lookups could result in even more IP addresses, or could time out.
If you have a configuration that would actually require that, then you
would have a case for using a wildcard. My complaint is that you're
trying to force everyone to pay for that feature whether it's of use to
them or not. I think it's at least as likely that typical setups would
need exactly *one*, non wildcard, entry, to wit appserver.mycompany.com
(which'd necessarily yield IPs for all the machines running your app
server code).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-10 15:22:23 | Re: Session timeout on commitfest.postgresql.org |
Previous Message | Kevin Grittner | 2010-08-10 15:05:46 | Re: Session timeout on commitfest.postgresql.org |