It seems to me this patch has been left for a long time, although it tries to provide a useful functionality.
In the previous discussion, several issues were pointed out. * Case handling when an IP-address has multiple hostnames. Steve Atkins noticed getaddrinfo() does not have capability to handle this case, because it returns just one hostname from the candidates. So, he suggested to use gethostbyaddr() instead, because it can return all the candidates of hostnames. I also think gethostbyaddr() is more prefereble here rather than getaddrinfo() with the primary hostname as a fallback. How about the following idea? 1. Add a list of hostname on Port structure to store all the candidates of hostnames for the current remote host. 2. Revise the pg_getnameinfo_all() to call the gethostbyaddr(), then it constructs the list from the returned hostent->h_aliases. 3. Revise Port->remote_host to indicate contents of the list head. 4. Revise the new check_hostname() to compare the supplied hostname from pg_hba.conf and each hostnames in the above list. If pg_getnameinfo_all() would have all the candidates of hostnames, we don't need to lookup dns twice on fallbacks. * "localhost" in the default pg_hba.conf Robert Haas disagreed to switch "localhost" in the default pg_hba.conf into numeric expression, because /etc/host should determine where the localhost shall be mapped. I agree with the opinion from Robert. We should not have any assumptions of /ets/hosts settings. * Cost for reverse lookup of DNS Tom Lane concerned about the cost to communicate with DNS for each connections. You answered either caching mechanism in PG or nscd is a solution, and agreed to add an explicit description about names being more expensive than IP addresses in pg_hba.conf. I also think it is fair enough. How about adding a recommendation to install nscd when people uses hostname in pg_hba.conf. Thanks, (2010/08/10 3:47), Peter Eisentraut wrote: > Here is a patch for host name support in pg_hba.conf. I have reviewed > various past threads about this, and there appeared to have been a 50/50 > split of for and against reverse lookup. I went with the reverse > lookup, because > > 0) I like it. > > 1) It is more secure. > > 2) It allows extending it to wildcards in the future. > > 3) Apache (Allow from) does it that way. > > To clarify how it works: The client's IP address (known from the > kernel) is reverse looked up, which results in a host name. That host > name is compared with the line in pg_hba.conf. If it matches, a forward > lookup is performed on the host name to check if any of the resulting IP > addresses match the client's IP address. If yes, the line is considered > to match and the authentication method is selected. > > Anyway, assuming we will go with this, you will also notice that in the > patch I changed the default pg_hba.conf to match against "localhost" > instead of numeric addresses. Initially thought of as a temporary > change for testing this patch, I think this might actually have some > permanent value because it saves you from having to change the IPv4 and > IPv6 lines in tandem most of the times, which is a moderately common > mistake. We already rely on localhost being (forward) resolvable for > the stats collector. > > Something to think about: Maybe we need a quoting mechanism in case > someone names their hosts "samenet". > > > > -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
