Re: pg_hba.conf hostname todo
От | Steve Atkins |
---|---|
Тема | Re: pg_hba.conf hostname todo |
Дата | |
Msg-id | E22BEA43-CFF7-4F95-81BB-0A71FBC1626E@blighty.com обсуждение исходный текст |
Ответ на | Re: pg_hba.conf hostname todo ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | 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@commandprompt.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
В списке pgsql-hackers по дате отправления: