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  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Re: host name support in pg_hba.conf  (Joachim Wieland <joe@mcknight.de>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Issues with Quorum Commit
Следующее
От: Tom Lane
Дата:
Сообщение: Re: leaky views, yet again