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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > krb5_sname_to_principal() will use the passed hostname for the second
> > component. If type is KRB5_NT_SRV_HST this name will be looked up with
> > gethostbyname(). If hostname is NULL, the local hostname will be used.
>
> > If we were passing in NULL before when hostaddr was set and host wasn't,
> > then we were probably ending up with Kerberos trying to use the local
> > hostname, which almost certainly wasn't right.
>
> Ah. I agree that that would be unexpected behavior.
>
> > I expect that the
> > correct answer here would be to do whatever the actual connection logic
> > does- if it connects using host, then use host, if it connects using
> > hostaddr, then use hostaddr.
>
> 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. Maybe I'm missing something, but hostaddr being an IP is
just like if you passed in host with an IP, which I believe is what psql
does when called like so:

beren:/home/sfrost> psql -h 172.18.148.12 -d gis
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

and that certainly works just fine.

beren:/home/sfrost> klist
[...]
07/14/10 17:37:50 07/14/10 17:58:25 postgres/beren(dot)tsf(dot)noblis(dot)org(at)TSF(dot)NOBLIS(dot)ORG

> At this point I'm satisfied that what the code is doing is right. We
> can't authenticate against Kerberos without knowing the server host
> name, because we can't form a correct principal name. Whether use of
> hostaddr would avoid an rDNS lookup inside the library is not relevant.

I don't believe anything is going to avoid an rDNS lookup except bombing
out before invoking krb5_sname_to_principal(). Perhaps that's what's
intended, to avoid any DNS lookup, but I don't believe it's because it
wouldn't *work* to give krb5_sname_to_principal() an IP address
(provided rDNS is, in fact, functional in your environment).

Thanks,

Stephen