[6565] in Kerberos
Re: Anyone know of fixes for these problems?
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Feb 1 14:24:50 1996
To: schroede@number6.sdsc.edu (Wayne Schroeder)
Cc: kerberos@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 01 Feb 1996 14:02:43 -0500
In-Reply-To: schroede@number6.sdsc.edu's message of 31 Jan 1996 21:15:42 GMT
>>>>> "Wayne" == Wayne Schroeder <schroede@number6.sdsc.edu> writes:
Wayne> We've been working with K5 Beta 4 release 3 for about a
Wayne> year now (off and on) and now have many of the kerberized
Wayne> utilities working fairly well on many of our platforms.
Wayne> We've tracked down and fixed quite a few problems
Wayne> especially on our Cray, SGIs, and Alphas, especially in the
Wayne> utilities and daemons. We passed these mods back to MIT
Wayne> last September.
Unfortunately, we weren't able to apply as many of these
patches as you might like; our tree has diverged so much from Beta 4-3
that the code you were fixing didn't always exist. In many cases, you
will find that we already fixed the bug; in other cases, you may find
that we did not. We no longer have a Cray; see below for some bad
news about telnetd and rlogind on the Cray. We have SGIs, and a
member of the Kerberos team was working on getting the utilities
working better on the SGIs.
I think it works fairly well on the Alpha in our current tree,
but was fairly broken in Beta 5.
Wayne> We still see a few problems and are in the process of
Wayne> deciding how to proceed, ie wait for and install K5B6, try
Wayne> K5B5, or continue working with our modified version of
Wayne> K5B4. K5B6 should have many of our mods and both K5B5 and
Wayne> K5B6 will have many improvements.
I would strongly advise you to avoid K5B5; it won't work very
well at all on your hardware--I doubt it'll even compile on the SGIs.
K5B6 should compile fine on the SGI and Alpha, and compile with a few
fixes on the Cray. (I don't know of any Cray problems, but suspect
there will be some.) It should work basically without modification on
the Alpha.
Between Beta5 and Beta6, I significantly reworked utmp and pty
handling, centralizing the code in both krlogind and telnetd into one
library. Unfortunately, my changes did not take into account the Cray
user database, security options, setting up of a temporary directory,
causing init to spawn login even for telnetd, etc. I believe the
current code in telnetd is poorly abstracted with regard to the Cray.
This means I would rather not make my new library work like the code
in telnetd. In other words, getting K5B6 to work like the native Cray
utilities would be difficult. I see two options. You could create
patches that duplicate the poorly abstracted telnetd code in my
library; this would be moderately difficutl, but we would be unlikely
to accept these patches, so you would have to continue maintaining
them as new versions are released. You could also look at adding
hooks and layers to the new library that allow the right thing to
happen on a Cray and could be used generally to interface to simlilar
features in other operating systems. Naturally, this is the approach
we would rather see happen, but it's always easier to say you want to
see things done right when you're not paying for it. You might also be
able to just remove the Cray specific features from telnetd and
rlogind if you don't need them.
The SGI may need a bit of work, but nothing like the Cray. In
particular, I haven't decided how I want to get a pty on the SGI.
(There's the obvious and SGI-recommended way of calling _getpty, but
I really don't want to use an OS-specific interface if I can get a
standard mechanism working.) I'm not sure that I'll have enough time
before K5B6 to examine the problem, pound my head against the wall
enough to convince me to stick in the _getpty patch, and implement the
fix. However, this should only be about 10-20 lines of code, so it
shouldn't be a major problem.
Wayne> The following is a list of the more significant problems we
Wayne> currently see. For many of these, our best bet may be to
Wayne> wait for K5B6 and then work with that. But if localized
Wayne> mods are available in K5B5 or from the community, we may
Wayne> want to integrate those changes into our version.
Wayne> A krlogin -x connection from an Alpha to a Sun gets an
Wayne> immediately close (I believe a read size error occurs); to
Wayne> our Cray authentication fails (it prompts for a password),
Wayne> but it does function.
I suspect this is fixed; that code has been worked over
significantly. I don't know if the work over happened before or after
Beta5.
Wayne> Using the Alpha kerberos telnetd, environment variable
Wayne> 'term' is set to 'su'. (This seems to be new, possibly
Wayne> caused by something in our environment.)
Not sure if this is fixed our current code yet, so it may
still happen in K5B6.
Wayne> Using ktelnet/ktelnetd logging into an Alpha, even after
Wayne> setting term to 'xterm', vi only displays 8 lines (altho
Wayne> 'man' and other programs recognize the correct size).
This should be fixed in K5B6.
Wayne> The SGI version of kerberos telnetd and krlogind do not
Wayne> update wtmp correctly. Output from 'last' is not
Wayne> completely accurate. (We've made some changes to get this
Wayne> working better, but it is still not completely right.)
This should work much better, although I'm not sure it will
work exactly perfectly. It may require a minor change or two.
Wayne> Using SGI ktelnet, double control-Cs causes a disconnect
Wayne> (at least when connected to our Cray).
Several problems of this type have been fixed; I believe this
no longer happens.
Wayne> Using the SGI ktelnet to a Sun, the file completion
Wayne> function does not work (where one types escape and a
Wayne> partial file name should be filled in).
Strange; I have a few ideas, and suspect it should be fixed,
but am not sure.
Wayne> krcp is not yet operational for us on some platforms;
Wayne> Alphas, in particular, I believe.
It should be much happier in K5B6; several bugs have been
fixed, and it no longer requires you to have tickets on the
destination system for encryption to work.
Drop me a note if you would be interested in looking at the
changes or the current code; K5B6 isn't ready yet, but the client code
Wayne> Thanks.
Wayne> Wayne Schroeder Senior Systems Programmer/Analyst,
Wayne> "Principal Scientist" San Diego Supercomputer Center
Wayne> http://www.sdsc.edu/SDSC/Staff/schroede/Home.html
