[1097] in linux-net channel archive
login, telnetd and utmp
daemon@ATHENA.MIT.EDU (Marek Michalkiewicz)
Wed Sep 13 18:49:33 1995
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
To: linux-net@vger.rutgers.edu
Date: Wed, 13 Sep 1995 17:48:00 +0200 (MET DST)
Hi,
after looking at various login sources which all claim to support Linux
(util-linux, shadow, logdaemon) I noticed that we have no standard way
of utmp handling. The problem is that we have a SysV-style utmp but
we use BSD-style networking programs like telnetd and rlogind.
The version of login from util-linux creates an utmp entry if there is
none, the version from the shadow suite requires a valid utmp entry
when run without any flags (like -h from telnetd), the version from
logdaemon-4.9 always insists on a valid utmp entry (and works with the
supplied telnetd which creates one, but not with the standard Linux
telnetd from NetKit-B).
In addition, login from util-linux does a hostname lookup to fill in
the ut_addr field with the IP address corresponding to the name given
after the -h option. In a typical setup with tcp wrappers, this means
four DNS lookups:
- tcp wrapper does two lookups (IP -> name and then name -> IP to verify
that the two IP addresses match)
- telnetd does getpeername() and one IP -> name lookup for login -h
- login does a name -> IP lookup to fill in ut_addr
Of course, every DNS lookup takes some time, especially if the nameserver
is down... I am proposing the following:
- modify telnetd to create an utmp entry with all known fields filled in
(including ut_line: why use slow ttyname() if telnetd already knows
the tty name?) and add a built-in tcp wrapper (using libwrap.a from
tcp-wrappers-7.2)
- modify login to require a valid utmp entry for the current process
(like SysV login does) and don't fill in the ut_addr field
This saves us two DNS lookup for every incoming telnet connection (only
2 instead of 4 DNS lookups, because the tcp wrapper part knows the name
and IP address of the remote host). The telnetd changes apply to rlogind
too, of course.
The first change can be done now: it doesn't break anything, and the
existing login should work happily with the new telnetd. The change in
login requires that we have the new telnetd/rlogind, and can be done
later (it will in my rewrite of the shadow suite, when it is done :-).
Comments?
Marek
