[1133] in SIPB_Linux_Development
Bug in kerberized telnet to athena.dialup.mit.edu w/ recent named
daemon@ATHENA.MIT.EDU (Derek Atkins)
Mon Oct 30 14:29:11 1995
Date: Mon, 30 Oct 1995 11:25:51 -0800
From: Derek Atkins <warlord@Eng.Sun.COM>
To: linux-dev@MIT.EDU
Cc: krb5-bugs@MIT.EDU
I found a bug in Athena's telnet when you try to telnet to a dialup
machine using the multi-IP alias and when you are running a recent
named.
The symptom I was seeing was that I was receiving an error from
krb_rd_req(). I did a little tracing, and found that I was resolving
the name properly and getting a valid kerberos ticket, and that ticket
_was_ being sent... However, I then noticed that it was sending the
WRONG ticket! For example, telnet would connect to al-forno but send
it an rcmd.cacciatore ticket!
I finally figured out the problem: newer versions of named to IP
address round-robin automatically. What telnet does is approximately
this:
hp = gethostbyname(athena.dialup.mit.edu)
connect (hp->h_addr);
hp = gethostbyname (athena.dialup.mit.edu)
hp = gethostbyaddr (hp->h_addr)
instance = krb_get_phost (hp->h_name);
realm = krb_realmofhost (hp->h_name);
Unfortunately, between the first and second gethostbyname calls, the
nameserver will switch the order of the IP addresses, and the
gethostbyaddr() will return a different host than the one conencting
to it.
IMHO, the appropriate fix would be to save off the struct sockaddr_in
used in the connect call (in commands.c), and then perform the
gethostbyaddr() on that value to find the name of the connected host
for the ticket name (in kerberos.c), rather than relying on forward
and then reverse resolution to work properly.
I know this is a problem under Linux, as recent linux distributions
are running a named that round-robins IP addresses. On the other
hand, Sam asked me to send this to krb5-bugs as well. I do not know
if this bug exists in the athena sources or telnet locker sources, as
my only testing has been on Linux.
I dont have the time, now, to come up with a real fix for this
problem. I might have time around Thanksgiving time. Hopefully
someone will take the initiative and fix this.
-derek
PS: It will probably be a problem under NetBSD as well, if it uses
a recent enough BIND.
