[1103] in linux-net channel archive

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post