Re: BUG #5559: Full SSL verification fails when hostaddr provided - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #5559: Full SSL verification fails when hostaddr provided
Date
Msg-id 20100714212805.GP21875@tamriel.snowman.net
Whole thread Raw
In response to Re: BUG #5559: Full SSL verification fails when hostaddr provided  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5559: Full SSL verification fails when hostaddr provided  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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.
>=20
> 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 cr=
e-
     ation of ``service'' principals that can, for instance, be used to loo=
kup
     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 socke=
t,
     which should be a bound AF_INET or AF_INET6 socket.  There must be a m=
ap-
     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.=20=20

    Thanks,

        Stephen

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5559: Full SSL verification fails when hostaddr provided
Next
From: Tom Lane
Date:
Subject: Re: BUG #5559: Full SSL verification fails when hostaddr provided