Re: small issue with host names in hba

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 9, 2011 at 2:16 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> But I'm a little confused by what this code is really trying
>> to accomplish: ...

> I think the intended behavior of NI_NUMERICHOST is to suppress the
> name lookup, and return the text format *even if* the name lookup
> would have worked. So the intention of this code may be to ensure
> that we convert the the sockaddr to some sort of string even if we
> can't resolve the hostname - i.e. if the first call fails, try again
> with NI_NUMERICHOST added to make sure that we didn't fail solely due
> to some kind of DNS hiccup. I suspect that at some time this was
> defending against an actual hazard but I don't know whether it's still
> a problem on modern operating systems.

POSIX v7 says

If the node's name cannot be located, the numeric form of the
address contained in the socket address structure pointed to by
the sa argument is returned instead of its name.

If you read a bit further, apparently this is just supposed to be the
default behavior if neither NI_NUMERICHOST nor NI_NAMEREQD is set (in
the first case, it doesn't try to locate a node name, and in the second,
it fails if it can't locate a node name). But certainly the dance in
postmaster.c is not necessary if you believe the spec.

I believe that the existing coding is meant to cope with the behavior of
our stub version of getnameinfo(), which simply fails outright if
NI_NUMERICHOST isn't set. However, if we just removed that test and
behaved as per spec (return a numeric address anyway), then we could
eliminate the second call in postmaster.c.

>> The fix would appear to be using the NI_NAMEREQD flag to getnameinfo.

> If you want to do that, you're going to have to fix the version of
> getnameinfo() in src/port/getaddrinfo.c, which apparently doesn't
> support that flag.

Well, it's not just that it "doesn't support that flag". It's
fundamentally incapable of returning anything but a numeric address,
and therefore the only "support" it could offer would be to fail. So
that approach seems like a dead end.

I don't really think that there's anything to fix here with respect to
Peter's original concern, but it might be worth getting rid of the
double call in postmaster.c.

regards, tom lane