On 01/30/2013 01:54 PM, Gordon Messmer wrote:
On 01/28/2013 07:46 PM, Ed Greshko wrote:
> Has anyone configured telnetd for use on F18? Running 64 bit....but
> this shouldn't make a difference.
Actually, it might. I ran strace on the telnetd process, which should mostly proxy data
between a child process (login, at that point) and the socket. It isn't. I just
looked at the spec in git; there don't appear to be any changes since F17. Any bug
that's new to F18 would have to be external to telnetd's source.
Well, you brought up an interesting point. And, indeed, it does seem to be something
external to telnetd. The version of f17 is 0.17-53 while f18 is 0.17-54. So made the
mistake, again, of assuming.
I just installed the f17 rpm on the f18 system and it fails in the same way.
As long as you're concerned with compatibility over security, have you considered
using rsh instead? As much a problem as telnet is where security is involved, the biggest
one you face now is finding anyone motivated to fix it. telnetd is more complicated than
you think, probably. It's not a simply proxy to a local process/tty. The client and
server actually exchange a bunch of options in a binary handshake. Finding the bug could
take a while if you can't get the author's attention, and I don't think that
code has been maintained for a long time.
Sorry, not looking for a replacement. I'm also not going to explain the environment
which makes changing things impossible. If it never gets fixed, well so be it. It only
affects 2 users in a closed environment. Not upgrading their systems to f18 won't
impact their ability to do their jobs so their management could care less. Their
management would probably prefer they used RHEL or CentOS anyway.
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled