When a host name is used in pg_hba.conf, then we call
pg_getnameinfo_all() to get the host name for the client's IP address,
either in postmaster.c or in hba.c, whichever happens first. But if the
IP address has no host name, the getnameinfo calls return the IP address
in text form, which is then stored into port->remote_hostname as the
"host name". This "host name" is then compared to the name in
pg_hba.conf. It cannot match, because we only do this dance if the
entry in pg_hba.conf does not parse as an IP address. So I don't think
there is a direct security problem here, but it still seems odd.
The fix would appear to be using the NI_NAMEREQD flag to getnameinfo.
We could do that in hba.c, but in postmaster.c we would have to move
some code around to maintain a string version of the IP address for
logging. But I'm a little confused by what this code is really trying
to accomplish:
if (pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
remote_host, sizeof(remote_host),
remote_port, sizeof(remote_port),
(log_hostname ? 0 : NI_NUMERICHOST) | NI_NUMERICSERV))
{
int ret = pg_getnameinfo_all(&port->raddr.addr,
port->raddr.salen,
remote_host, sizeof(remote_host),
remote_port, sizeof(remote_port),
NI_NUMERICHOST | NI_NUMERICSERV);
if (ret)
ereport(WARNING,
(errmsg_internal("pg_getnameinfo_all() failed: %s",
gai_strerror(ret))));
}
If log_hostname is off, this just make the same function call twice. If
log_hostname is on (which is what we are concerned about here), it makes
the same call but with the addition of the NI_NUMERICHOST flag. But
getnameinfo already returns a numeric representation of no actual host
name is available, unless said NI_NAMEREQD is used.
So, do we need to fix the issue described in the first paragraph?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
