[858] in Kerberos-V5-bugs
a few comments on kerberos 5 beta 4-3
daemon@ATHENA.MIT.EDU (E. Jay Berkenbilt)
Fri Oct 14 10:23:40 1994
Date: Fri, 14 Oct 94 09:56:13 EDT
From: ejb@ERA.COM (E. Jay Berkenbilt)
To: krb5-bugs@MIT.EDU
Well, after a long break from Kerberos, my withdrawal symptoms
got to be too much to deal with, so I decided to grab kerberos 5
and play around. I have several comments:
1. The autoconf stuff is great. It's so much better than
imake. I've already raved about that, though, so no need to
do so now. You should take a good look at autoconf 2.0
(still alpha -- last I checked it was autoconf 1.120) which
has configure caches and better support for recursion. I
don't know what cygnus is doing with this. Anyway, the
configure step took a long time and kept figuring out the
same things over and over again. A cache file would
probably speed this up dramatically.
2. There is a way of overriding KRB5ROOT from configure, but I
didn't see a way of overriding KDB5DIR. In my small
environment, everyone shares /usr/local. I have krb.realms
and krb.conf in /usr/local/lib/krb5 and the kdb stuff in
/etc/krb5. This way, no client workstations need to be
modified to use kerberos. Since aname is really a local
file, I could change this in osconf.h to point to a local
path or could make symbolic links in /usr/local/lib/krb5 to
a local file.
3. Even without KRBCONF_VAGUE_ERRORS defined, kerberos error
messages are unnecessarily vague. There is a certain amount
of laziness here, I think. As an example, I was trying to
use the new kerberos 5 telnet. I know that I need some kind
of keytab on the server in order to do any authenticated
service, but I don't know what keys need to be created.
Likewise for being able to change passwords. (The key
changepw.kerberos sticks in my mind from V4, but kdb5_edit
didn't let me add that to the database with ark. I haven't
investigated yet. When I try to do one of these operations,
I get an error like "can't find key in database" or one of
the standard et messages defined for kerberos. The code at
the point where the error is issued knows what keys its
looking for. That information should be in the error
messages! This is one of the disadvantages of something
like com_err. It makes it too tempting to be lazy with
error messages. If the normal case is is that just printing
the standard error is good enough, it is still okay to check
the error code and decide based on it whether it is
necessary to print a more helpful error message. Someone
with as much background in kerberos as I have (which is a
lot for V4, but barely any for V5 except for some of the
early design meetings) should be able to set up a working
realm and services without having to read through the code,
IMHO [not that I mind reading the code ;-)].
4. Manual pages for krb.conf and krb.realms didn't get
installed in man5. Maybe the make install doesn't descend
into the config-files directory. I haven't really looked at
it.
Unfortunately, my work with kerberos here is strictly on my own
time. We are thinking of connecting to the internet for real
(instead of through uucp) soon, and I'd like to be able to set a
realm up in that case. Also, we finally have a server in a
machine room instead of just using a desktop workstation in a
lab also as a server. For this reason, it makes sense for me to
start using kerberos to control access to it. However, I have
very little time to play with it. If I fix any of the error
messages while trying to find information that the code knows
and isn't reporting, I'll send patches to this list unless
someone informs me that there is another place to send them.
Also, does mail to this list gateway to comp.protocols.kerberos
or is that just mail to the kerberos list? I'd be interested in
hearing about updates when they're available as long as that
doesn't involve being on a list that gets a whole lot of
traffic. If it does, I'll just check the ftp site every now and
then. ;-)
By the way, I should note that I had no trouble at all
installing kerberos 5 here (SunOS 4.1.3_U1B a.k.a.
Solaris 1.1.1B) and that I am grateful that kerberos didn't
require me to write into the system in any place other than
where I told it. That way, I could install kerberos in a
private area to play with it before making modifications that
would be hard to back it if necessary.
--
E. Jay Berkenbilt (ejb@ERA.COM)
Engineering Research Associates
formerly qjb@MIT.EDU
