Re: pg_hba.conf hostname todo

From: Steve Atkins <steve(at)blighty(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_hba.conf hostname todo
Date: 2006-12-27 22:08:55
Message-ID: E22BEA43-CFF7-4F95-81BB-0A71FBC1626E@blighty.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Dec 27, 2006, at 1:47 PM, Joshua D. Drake wrote:

> On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
>> * Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
>>> Allow pg_hba.conf to specify host names along with IP addresses
>>
>> Excellent.
>>
>>> Host name lookup could occur when the postmaster reads the
>>> pg_hba.conf
>>> file, or when the backend starts. Another solution would be to
>>> reverse
>>> lookup the connection IP and check that hostname against the host
>>> names
>>> in pg_hba.conf. We could also then check that the host name maps
>>> to the
>>> IP address.
>>

Doing the DNS at connect time, not startup time is the right thing to
do. The
main reason to use hostnames rather than IP addresses (or domain
wildcards
vs CIDR blocks) is because you're expecting the mapping to change. You
really don't want to add "restart all our postgresql instances" to
the DNS managers
"I changed a hostname" checklist.

>> I'm inclined towards doing the reverse-DNS of the connecting IP
>> and then
>> checking that the forward of that matches.
>
> Hmm what if it doesn't? Which is the case any many scenario. My
> thoughts
> are:
>
> If www.commandprompt.com is allowed, then the ip address
> 207.173.200.129
> is allowed to connect.

DNS is cheap. For the simple case it wouldn't be too hard to expand
all the given
hostnames at connect time, but there's a problem ...

> If we go the reverse way:
>
> 129.200.173.207.in-addr.arpa name = 129.commandprompt.com.
>
> Which really isn't that useful imo.

... unfortunately, you need to do it that way if you want to support
wildcards, as there's no way to expand *.example.com to a list of
IP addresses.

>
>>
>>> Allow one to specify a FQDN or a simple wild card DN. E.g;
>>> *.commandprompt.com.
>>>
>>> A valid entry would look like this:
>>>
>>> host all all *.commandprompt.com trust
>>> host all all www1.postgresql.org md5
>>>
>>> Thoughts?
>>
>> While a wildcard does make sense (ie: www*.postgresql.org) I would
>> generally expect 'commandprompt.com' to mean '*.commandprompt.com'
>> implicitly.
>
> Hmm interesting. I wouldn't expect that. I might
> expect .commandprompt.com to mean *.commandprompt.com. But
> commandprompt.com I would expect only whatever the A record returns as
> commandprompt.com.

> One thing I don't want to do is create a bunch of different style
> syntaxes that are available :)

tcp_wrappers (/etc/hosts.allow and friends) are one fairly widely
used standard for this, and one that's mostly compatible with the
existing usage for dotted quads, I think. It uses ".example.com"
to match anything that ends in "example.com".

(If you're going down that road you can also have a "host" that
begins with a "/" to refer to an external list of filenames, but that
way may lie madness.)

Cheers,
Steve

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-12-27 22:16:58 Re: pg_hba.conf hostname todo
Previous Message Bruce Momjian 2006-12-27 22:08:01 Re: Per-database search_path