Re: host name support in pg_hba.conf - Mailing list pgsql-hackers

From Robert Haas
Subject Re: host name support in pg_hba.conf
Date
Msg-id AANLkTi=1sAWvRoTqy6MRFjp38QdzinZo7+LB5kuObq+2@mail.gmail.com
Whole thread Raw
In response to host name support in pg_hba.conf  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: host name support in pg_hba.conf
List pgsql-hackers
On Mon, Aug 9, 2010 at 2:47 PM, Peter Eisentraut <peter_e@gmx.net> 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.

Seems reasonable.

> 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.

-1 from me, on this part.  I think we should be trying to eliminate
any dependencies we have on how localhost resolves, and we certainly
should not add more.  I have spent way too much time fighting with
problems caused by localhost being present/absent in /etc/hosts; and
more caused by whether it maps to 127.0.0.1 or some IP assigned to one
of the boxes' Ethernet cards.  What's really special is when you have
two parts of the system, one of which will only work with one version
of /etc/hosts and the other of which will only work with a different
version.  I humbly, but fervently, suggest that we try to avoid being
polemical about this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: Re: dynamically allocating chunks from shared memory
Next
From: Markus Wanner
Date:
Subject: Re: dynamically allocating chunks from shared memory