Skip site navigation (1) Skip section navigation (2)

Re: small issue with host names in hba

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: small issue with host names in hba
Date: 2012-10-02 01:01:29
Message-ID: 1349139689.3584.33.camel@vanquo.pezone.net (view raw or flat)
Thread:
Lists: 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(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. +
> 
> 



Attachment: pg-getnameinfo.patch
Description: text/x-patch (2.0 KB)

In response to

pgsql-hackers by date

Next:From: Noah MischDate: 2012-10-02 01:12:01
Subject: Re: Visual Studio 2012 RC
Previous:From: Peter EisentrautDate: 2012-10-02 00:57:18
Subject: small LDAP error message change

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group