Re: BUG #5559: Full SSL verification fails when hostaddr provided
От | Stephen Frost |
---|---|
Тема | Re: BUG #5559: Full SSL verification fails when hostaddr provided |
Дата | |
Msg-id | 20100714212805.GP21875@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: BUG #5559: Full SSL verification fails when hostaddr provided (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5559: Full SSL verification fails when hostaddr provided
|
Список | 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 по дате отправления: