Re: small issue with host names in hba

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: small issue with host names in hba
Date: 2012-08-14 22:52:42
Message-ID: 20120814225242.GB28155@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I assume we didn't feel any action was necessary on this issue.

---------------------------------------------------------------------------

On Thu, Aug 11, 2011 at 01:50:02PM -0400, Tom Lane wrote:
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-08-14 22:53:49 Re: -Wformat-zero-length
Previous Message Bruce Momjian 2012-08-14 22:43:32 Re: -Wformat-zero-length