[1103] in linux-net channel archive
Re: login, telnetd and utmp
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Sep 14 22:05:55 1995
Date: Thu, 14 Sep 1995 16:40:31 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Cc: linux-net@vger.rutgers.edu
In-Reply-To: Marek Michalkiewicz's message of Thu, 14 Sep 1995 20:47:23 +0200 (MET DST),
<199509141847.UAA10676@i17linuxb.ists.pwr.wroc.pl>
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Date: Thu, 14 Sep 1995 20:47:23 +0200 (MET DST)
OK, but I think we should require a utmp entry to make sure that the user
does "exec login" and not just "login" from the shell prompt (the current
shell should be replaced by the login program).
I don't understand your point. #1, why do we care whether the user did
"exec login" or just "login" from the shell prompt, and #2, no matter
whether the user types "exec login" or "login" the currently existing
utmp entry will still be there, so it won't make any difference in any
case.
Backward compatibility should not be a problem - it will take a few months
before I will need beta testers for my version of the shadow suite, and it
will probably only support libc 5.x (because I use the NYS library), so if
we make the change in telnetd/rlogind (and any other programs which need
to execute /bin/login and don't create a utmp entry - are there any such
programs other than telnetd and rlogind?) now or in the near future (I can
provide patches if necessary), chances are everyone will be using the new
telnetd before the new login will be available.
This is a very bad assumption. Not everyone upgrades their binaries
often; some of my binaries are years old. Furthermore, many people
upgrade things in piecemeal fashion, and if we change the behavior of
the login in the utils package, users will be very unhappy if they
install a new version of the utils package in order to get some
completely unrelated functionality, and their telnetd/rlogind servers
break because they're still using old telnetd or rlogind binaries.
One of the strengths of Linux is that we've generally kept backwards
compatibility unless it's absolutely necessary to break stuff. Indeed,
binaries compiled from 0.99 will generally work today, and there are
people who rely on it. We need to treat backwards compatibility
seriously.
- Ted