[9366] in Athena Bugs
Re: vax 7.4C: /bin/login
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed May 27 01:38:59 1992
Date: Wed, 27 May 92 01:38:23 -0400
To: ckclark@MIT.EDU
Cc: "Richard Basch" <basch@MIT.EDU>, testers@MIT.EDU, bugs@MIT.EDU
In-Reply-To: Calvin Clark's message of Wed, 27 May 92 01:09:21 -0400,
From: "Richard Basch" <basch@MIT.EDU>
Date: Wed, 27 May 92 01:09:21 -0400
From: Calvin Clark <ckclark@MIT.EDU>
References: <9205270148.AA00464@oliver.MIT.EDU>
<9205270355.AA04327@tardis.MIT.EDU>
Reply-To: ckclark@MIT.EDU
>>>>> On Tue, 26 May 92 23:55:05 -0400, "Richard Basch" <basch@MIT.EDU> said:
Richard> I would disagree; many people instinctively type
Richard> username followed by password, and if people are doing
Richard> things quickly, the password may end up on the screen
Richard> if the user is not careful.
You're spoiled by fast machines. Try logging into dialups often, and
you will be corrected of this habit. Seriously, it's an argument I
hadn't thought of. My objections to the current behavior are:
a) It's different from the implementations of "noremote"
login I've seen in the past, including the one currently
running on podge and hodge in the SIPB office (written by
jik?) (This isn't a very good argument, since noremote
hasn't seen a release until now, and claiming precedent
on the variety of hacked versions that existed before
is not convincing.)
Hmm... I could have sworn that the original "noremote" implementation
did it (I was the culprit who started it, and then jik, while he was a
consultant asked me for a copy, and then it took off...) Anyway, I
implemented it in the same manner that it would prompt for your password
on the local system even if you couldn't login, to maintain a consistent
interface (and for the reasons that you cited me).
b) It's not intuitive. The machine is rejecting you because
you are not in the password file. It doesn't need your
password to determine that, so it shouldn't read it.
c) The password read for a user who is punted because
he's not in the password file is
------> NEVER bzero'd <------
(I have verified this by compiling login with
a quick hack version of bzero which prints out
what it's trying to bzero.)
So if you are going to keep the interface, at least
fix this.
I agree wholeheartedly with (c)... I made sure when I did the RISC/6000
version to simply read the password and zero it immediately when I knew
there was a failure.
-Richard
