Re: small issue with host names in hba - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Re: small issue with host names in hba |
Date | |
Msg-id | 1349139689.3584.33.camel@vanquo.pezone.net Whole thread Raw |
In response to | Re: small issue with host names in hba (Bruce Momjian <bruce@momjian.us>) |
List | pgsql-hackers |
On Tue, 2012-08-14 at 18:52 -0400, Bruce Momjian wrote: > I assume we didn't feel any action was necessary on this issue. I propose the attached patch to reduce the redundant code as discussed. > > --------------------------------------------------------------------------- > > On Thu, Aug 11, 2011 at 01:50:02PM -0400, Tom Lane wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > > > On Tue, Aug 9, 2011 at 2:16 PM, Peter Eisentraut <peter_e@gmx.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@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-hackers > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > >
Attachment
pgsql-hackers by date: