Re: host name support in pg_hba.conf
От | Peter Eisentraut |
---|---|
Тема | Re: host name support in pg_hba.conf |
Дата | |
Msg-id | 1286307678.16817.73.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | Re: host name support in pg_hba.conf (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: host name support in pg_hba.conf
Re: host name support in pg_hba.conf |
Список | pgsql-hackers |
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. > * "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. Note that this would only be a default. But if you think that it's the wrong default, then we should consider changing the listen_addresses default as well. The reason why I think this is semi-important and not just cosmetic is that (for some reason that is not entirely clear to me) clients connecting to localhost end up appearing to the server as ::1 on a lot of machines I use which are not otherwise keen on IPv6, and it is a common mistake to forget to keep the pg_hba.conf entries for 127.0.0.1 and ::1 in sync.
В списке pgsql-hackers по дате отправления: