Mark Woodward wrote:
Added to TODO:
o Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another
solution would be to reverse lookup the connection IP and
check that hostname against the host names in pg_hba.conf.
We could also then check that the host name maps to the IP
address.
I'm not so sure you need to be paranoid about it. The scenario is, at
startup or HUP, names are looked up and stored as IP addresses. Then hba
works as it is supposed too.
If you do it like that you destroy the only real use case I can see for
this that has much value, namely to handle cases where the address can
change dynamically.
"spoofing" is not really a problem, IMHO, because there should be a fire
wall between PostgreSQL (most services really) and the raw internet, *and*
the admin MUST have control over the authenticity of the name resolver. If
someone is in the position to spoof name resolution, they are probably
also in a position to spoof IP addresses.
While I do see a need for this, but not in a sense that any old name would
be used. I see it more like a data center wide "hosts" file use to
dedicate various IP addresses to various services, i.e. freedb, streetmap,
session, web0, web1, .., webn etc.
What also may be handy in this scenario is that the names must fall within
a range of acceptable addresses.
Range: 192.168.245.1 ... 192.168.254.254
joey (192.168.254.55) -- OK
joey (10.1.1.0) -- Not OK.
This would be useful to declare a range of addresses as having some level
of trust, and specific names within that range as having more (or less).
In this scenario, think of a VPN, "joey" may be a laptop, and while he is
on the VPN he is trusted, and when he is not on the vpn he is not trusted.
This is especially important with regards to cyber security.
We have address ranges now; are you proposing to have those IN ADDITION
to hostname parameters (as opposed to being an alternative)?
We can over-egg this pudding massively. I suggest we start with a simple
implementation and see what needs it leaves unfilled. I would vote for
allowing a hostname (or list of hostnames?) to replace the address/mask
params, and that at connect time we do a forward lookup trying for a
match with the connecting address. If we get a match then that's the hba
line that applies.
Frankly, any auth mechanism based on the name or address of the client
is insecure. If you have people connecting across possibly insecure
networks you should use SSL with client certificates signed by your own
CA, or a similar approach.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
