Re: host name support in pg_hba.conf

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