(2010/10/06 4:41), Peter Eisentraut wrote: > On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote: >> 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. > > I have several concerns about this approach. > > The first is conceptual: Assume that an IP address resolves as host > names "foo" and "bar", perhaps even by accident. You have log_hostnames > on, which would be typical if you have an all-names pg_hba.conf. > log_hostnames only logs the first host name, say, "foo". And then > assume that pg_hba.conf is set up to only allow "bar" in. There you > have a debugging and auditing nightmare, because what pg_hba.conf says > and what you are logging doesn't match. To address this you would have > to change the log_hostnames facility to log *all* host names everywhere > the host name is mentioned, which could make this whole thing quite > silly. > > Secondly, long-standing and presumably reputable implementations of a > similar feature, namely Apache's mod_authz_host and tcp-wrappers use > getnameinfo() in preference of gethostbyaddr(), and don't support > multiple host names per IP address. In fact, reading through that > source code indicates that gethostbyaddr() has all kinds of bugs and > issues, including apparently lack of IPv6 support (on some platforms?). > > Thirdly, gethostbyname() and gethostbyaddr() are deprecated by POSIX in > favor of getaddrinfo() and getnameinfo(), so we shouldn't build new > features that depend on them. > OK, it seems to me fair enough. I consented with your explanation.
I'll check the patch for more details, please wait for a few days. >> * "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. > > Note that we already default listen_addresses to 'localhost', so it > would only make sense to have pg_hba.conf behave the same by default. > To pick up on your argument, we effectively *do* make assumptions > about /etc/hosts now, and this change would remove them. > Sorry, I misread something. I read the previous discussions again, then I know I misread the reason why Robert disagreed with this replacement. He said we should not assume resolve of localhost being enough fast because of local /etc/hosts, not saying we should not assume localhost is "127.0.0.1" or "::1". Right? Well, in my personal opinion, we should not assume the way to resolve localhost, but we can expect more than 99.9% of hosts resolve localhost using local /etc/hosts. Even if here is a curious setting, it will pay a bit more cost on connection. It is a responsibility of DBA. I agree with replacement "127.0.0.1" and "::1" by "localhost". It enables to eliminate an assumption that localhost have either of their addresses. Thanks, -- 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
