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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Christopher Head <chris2k01(at)hotmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5559: Full SSL verification fails when hostaddr provided
Date: 2010-07-14 21:28:05
Message-ID: 20100714212805.GP21875@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I've never found a reason to use hostaddr, so I don't particularly care,
> > but it doesn't seem right to break Kerberos auth if you were only given
> > an IP address unless hostaddr's entire point is that it will prevent a
> > DNS lookup from happening, ever.
>
> Well, given your description we *can't* prevent Kerberos auth from doing
> a synchronous reverse-DNS lookup. So the question is why did that test
> get put in, back in 2005? I have no objection to removing it if that
> doesn't lead to crashing, but ...

We could prevent it by doing exactly what we're doing now- bailing if we
end up in the KRB5 code when hostaddr is passed in but host isn't. We
could justify that by saying that the user asked for no DNS lookups
(through the use of hostaddr) and that using Kerberos would then violate
that request, since it'd do an rDNS lookup.

I'd advocate *against* that, since it strikes me as bizarre, but having
the hostaddr option in the first place is a bit strange to me, so
perhaps I just don't run into the use-case it's built for enough to be
able to say it doesn't make sense.

In any case, here's what I believe the original issue was and what I
would suggest:

Per the documentation-

krb5_sname_to_principal() and krb5_sock_to_principal() are for easy cre-
ation of ``service'' principals that can, for instance, be used to lookup
a key in a keytab. For both functions the sname parameter will be used
for the first component of the created principal. If sname is NULL,
``host'' will be used instead.

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.

krb5_sock_to_principal() will use the ``sockname'' of the passed socket,
which should be a bound AF_INET or AF_INET6 socket. There must be a map-
ping between the address and ``sockname''. The function may try to
resolve the name in DNS.

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. 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.

An alternative might be to just use krb5_sock_to_principal(), since we
have the socket already.

Thanks,

Stephen

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-07-14 21:35:21 Re: BUG #5559: Full SSL verification fails when hostaddr provided
Previous Message Tom Lane 2010-07-14 19:20:09 Re: BUG #5559: Full SSL verification fails when hostaddr provided