Re: BUG #5559: Full SSL verification fails when hostaddr provided

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Uh, no, because hostaddr is (required to be) a numeric IP. The odds of
>> it being useful in this context seem negligible.

> Err, no, it'll work just fine- gethostbyname() will take the dotted-quad
> numeric IP and return the hostname and Kerberos will use that to generate
> the principal.

Hm. That might happen to work for Kerberos, but it won't work for
GSSAPI or SSPI --- in both those code paths we just push the host name
literally into a constructed principal string. Not sure if we really
want Kerberos to work differently from the more modern alternatives.

> Maybe I'm missing something, but hostaddr being an IP is
> just like if you passed in host with an IP,

No, it's entirely different. The point of hostaddr is to avoid doing a
forward DNS lookup inside PQconnect() when you would rather it be done
at some other time. It's not to substitute for actually knowing the
host name. I expect that typical applications making use of it would
essentially cache the hostaddr corresponding to host name and would be
able to pass both to libpq. The option to supply only hostaddr is just
there for cases where you truly don't need to know the host name, which
clearly does *not* include Kerberos auth.

The case you're describing could perfectly well be handled by passing
host as a numeric IP string, without using hostaddr; so I don't think
we are losing any functionality.

> I don't believe anything is going to avoid an rDNS lookup except bombing
> out before invoking krb5_sname_to_principal().

So it would seem. The bottom line is that if you don't want any DNS
activity to happen during PQconnect(), you can't use Kerberos auth.
What we allow or don't allow won't change that.

regards, tom lane