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

From Peter Eisentraut
Subject host name support in pg_hba.conf
Date
Msg-id 1281379676.23513.34.camel@vanquo.pezone.net
Whole thread Raw
Responses Re: host name support in pg_hba.conf  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: host name support in pg_hba.conf  (Thom Brown <thom@linux.com>)
Re: host name support in pg_hba.conf  (Robert Haas <robertmhaas@gmail.com>)
Re: host name support in pg_hba.conf  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: host name support in pg_hba.conf  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
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".

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: dynamically allocating chunks from shared memory
Next
From: Robert Haas
Date:
Subject: Re: dynamically allocating chunks from shared memory