Re: host name support in pg_hba.conf

(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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>