[900] in Kerberos-V5-bugs
Re: more smelly input from this end
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Oct 25 23:52:09 1994
Date: Tue, 25 Oct 1994 23:52:07 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: *Hobbit* <hobbit@asylum.sf.ca.us>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: [867]
Date: Tue, 18 Oct 1994 03:30:22 -0400
From: *Hobbit* <hobbit@asylum.sf.ca.us>
I can actually kinit, getting a tgt of "krbtgt.ELF.COM@ELF.COM" [ELF.COM is
the realm name I'm using for now] -- this looks bogus, especially when I
later try to use that and see the MIT workstation asking asylum's KDC
for principal "krbtgt", instance "SF.CA.US". Since v4 clients use dots to
separate principals and instances and v5 stuff uses slashes, how is
everything supposed to map?
I'm not sure what you mean by "how is stuff supposed to map"?
Basically, the V4 tgt would have been krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
(which, by the way, the V4 parsing routines won't parse because of the
periods in the instance name), and the V5 tgt would be
krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU.
v5-to-v5 rlogin fails with "bad response during sendauth", and I haven't
really managed to trace it any farther than that yet. Ideas? The bits of
code I looked at seemed to indicate that this should "never happen".
I can't reproduce this. What was the architectures of the client and
the server when you tried to reproduce this? There was a problem where
V4-to-V5 rlogin was failing because the compatibility code wasn't being
included properly in the libkrb5.a, but that will be fixed in the next
release.
The way to debug this sort of thing is to run both the client and the
server under gdb, using a debugging port, and setting a breakpoint in
krb5_recvauth and krb5_sendauth. Then step through, until you see
what's going on.....
I can't extract a srvtab for more than one instance name, for example
having host/asylum.sf.ca.us *and* host/localhost in the same srvtab.
Simply catting two srvtabs together doesn't work...
If you really want to, you can use the extract_srvtab command in
kdb5_edit, and then rename the output file to the other filename
(localhost-new-srvtab, for example), and then extract the new host.
This hasn't come up before because no one has had any reason to want to
extract two different instances into a srvtab file.
Why would you want to put host/localhost in a srvtab? That strikes me
as a really bad idea.....
I tried building the entire tree adding CCOPTS=-DDEBUG to the top level
make. This broke several things in lib/crypto/des and prevented them from
loading -- try it and see. I only did this in an attempt to get more
debugging information out of anything that had #ifdef DEBUGs in the code,
which is mighty sparse.
-DDEBUG isn't supported. As of patchlevel 3, there are no "#ifdef
DEBUG" in the des subdirectory at all.
I did find it somewhat instructive to turn on a "local6" file and get
syslog output from the KDC, which isn't documented.
I now know most of the principals I need to create for testing, but that
doesn't help the next poor schlunk who comes along to try building this.
Yes, I know we need installation documentation. We just haven't had the
time or manpower to write it yet. My apologies.....
Kadmind doesn't listen on the loopback interface, but the KDC does. Why?
The people who donated the kadmin code (from Sandia National Labs) did a
pretty iffy job of writing it (as I'm sure you've noticed). The only
reason why it's still in the distribution is that I haven't found
anything better to replace it with yet. The moment I do, I plan to
replace kadmin/kadmind. You should consider kadmin/kadmind as ALPHA
code; the protocol will likely change, when we replace it wholesale.
I'm sorry you're finding all of the rough spots in the Kerberos V5
distribution. We're trying to clean them up as fast as we can....
- Ted
