rjd@occrsh.ATT.COM (12/01/87)
> The manual pages for sys V unix state that the prompt you get to > log in comes from a field in gettydefs. In customizing my 3B2, I > edited the login field of this file that originally said "login:" > I changed the prompt to something different, but this new prompt > will only show up on the first login attempt. If this login fails > for some reason, the prompt goes back to "login:" even though I > have edited out every occurence of this prompt in /etc/gettydefs. As it should be. First a lesson on the sequence of events up to the point in question that happen when a user logs in: 1) /etc/getty is the first program run on a port (started by /etc/init according to the information in /etc/inittab). It sets up the initial port protocol (as defined in gettydefs) and gives the login message (also specified in gettydefs). 2) Once a user (or whatever) responds to that, possibly customized, login prompt, the getty performs an exec of the form: login <your response to the getty login: prompt> 3) The login program then searches the /etc/passwd file to see if the login exists and if so, if it has a password. If it does not exist or does and has a password, the program prompts for it. 4) Now here's the part you are interested in: If the login does not exist and anything is entered or if the login exists, is passworded, and the incorrect password is entered, the *login* program prints the "Login incorrect" message and then RE-PROMPTS FOR THE LOGIN ID with its own prompt, which is "login:".... So your solution is to either modify the /bin/login program with your new prompt or have the login program terminate after an incorrect attempt (maybe by picking a short timeout interval for getty, which does not sound like a very good method to me.) If you enter a "control-d" at this /bin/login login: prompt, it will exit and return you to init, which will start up the getty running at the protocols set up in gettydefs, thus reprinting the /etc/gettydefs login prompt. Randy
lukas@ihlpf.ATT.COM (Lukas) (12/03/87)
In article <142700001@occrsh.ATT.COM> rjd@occrsh.ATT.COM writes: > (Lots of stuff concerning the getty - login sequence) Believe me, Im a novice at this. But it occurred to me . . . Does it make sense for login, after an invalid password, to exec getty rather than issue its own login: prompt? This would eliminate the two login: prompts (surely a goodness), but would it tie login too closely to getty? I dont know, just ruminating. -- John Lukas ihnp4!ihlpf!lukas 312-510-6290
rjd@occrsh.ATT.COM (12/05/87)
> > (Lots of stuff concerning the getty - login sequence) > > Believe me, Im a novice at this. But it occurred to me . . . > > Does it make sense for login, after an invalid password, to exec getty > rather than issue its own login: prompt? This would eliminate the two > login: prompts (surely a goodness), but would it tie login too closely > to getty? > > I dont know, just ruminating. Sounds good to me, especially for the guy who asked the original question... To actually implement would be slightly harder, as getty expects the gettydefs line to get the parameters to set the port to, which the login program does not know. Maybe change both login and getty to check another file for the login prompt and keep the sequence the same, or have just login only prompt for it (which I see problems with), or........ EDUCATE the users to not be bothered by it......Na, thats too easy... Randy
dipto@umbc3.UUCP (12/05/87)
In article <2932@ihlpf.ATT.COM> lukas@ihlpf.UUCP (00704a-Lukas,J.) writes: >In article <142700001@occrsh.ATT.COM> rjd@occrsh.ATT.COM writes: >> (Lots of stuff concerning the getty - login sequence) > >Believe me, Im a novice at this. But it occurred to me . . . >Does it make sense for login, after an invalid password, to exec getty >... When one signs on a special prog called "init" gets executed. "Init" is a process control initialization program. "Init" creates a process for each terminal port where a user may log in. Thereafter "getty" executes. It initializes a terminal line, and gets the userid (this is when the ``login: '' prompt appears). It subsequently starts up the program "login" (user asked for ``passwd:''). Upon execution, "login" performs a few critical tasks like initializing the uid & gid, along with the environment and terminal type. Subsequently, this "login" program executes the command interpreter sh, csh, or tcsh. So, remember that it is "getty" which asks for ``login:'' and not the prog login itself; that's the reason why a passwd can't be typed in before being prompted for it on the Unix. Happy logging in ... -- BITNET : dipto@umbc2 ------\ ARPANET: dipto@umbc3.UMD.EDU -------> In-real-life: Dipto Chakravarty USMAIL : CMSC, UMBC,Md 21228 ------/
ron@topaz.rutgers.edu (Ron Natalie) (12/06/87)
No, it would be far better if getty didn't attempt to pretend it was login at all. However, it likes to do so so it can do things like autobauding and trying to guess what you want for terminal modes. - -ROn
ron@topaz.rutgers.edu (Ron Natalie) (12/06/87)
The previous poster was wrong. After init opens the terminal line (which either happens immediately, or when carrier is asserted), getty is executed. Getty initializes the stty modes as if it wants to see it, prints the login prompt and reads at most one line of input. On the basis of this line of input, it changes the terminal modes some more (autobauding, parity, cr mapping, etc..) and calls login. If you had typed something that looked like a username, login asks for a password. If not, then login prompts for the username again. In any case after the first input, you are always talking to login until it starts your shell up. -RON
meissner@xyzzy.UUCP (Michael Meissner) (12/06/87)
In article <623@umbc3.UMD.EDU> dipto@umbc3.UMD.EDU (Dipto Chakravarty) writes: (various correct information about the login sequence omited) > So, remember that it is "getty" which asks for ``login:'' and not the prog > login itself; that's the reason why a passwd can't be typed in before being > prompted for it on the Unix. That is not the whole story. If it was just limited to getty exec'ing to login, everything would be hunky dory. The problem is login calls the getpass function, which under BSD does a TIOCSETP ioctl, and under System V does a TCSETAF ioctl. Both of these ioctl's specify that the system is to wait until the terminal control buffers are empty before applying the ioctl. Also, in grepping the source, I noticed the 4.3 login.c also does an additional TIOCSETP on it's own. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa/Csnet: meissner@dg-rtp.DG.COM
rjd@occrsh.ATT.COM.UUCP (12/06/87)
> >Believe me, Im a novice at this. But it occurred to me . . . > >Does it make sense for login, after an invalid password, to exec getty > >... > > ........ > So, remember that it is "getty" which asks for ``login:'' and not the prog > login itself; that's the reason why a passwd can't be typed in before being > prompted for it on the Unix. Uuuummm, go re-read my artical (the base note) again. Login(1) DOES prompt for the login id if: 1) the login id is invalid (after prompting for the password anyway), or 2) the password entered to a valid login was incorrect. And no, that is NOT the reason the password cannot be entered before it is prompted. The reason you must wait for the prompt is that the "gpass" routine is used to prompt for the password, which, directly prior to printing the prompt (and setting echo to off), a fflush(stdin) is performed (which zeros out the input queue so no characters, no matter how many WERE there, are waiting to be read). If the fflush was not performed, the characters typed before the password prompt would still be in the input stream and thus still be available, no matter which program tried to read the input stream. This was implemented, I assume, to prevent users from getting in the habit of typing the password while it would be visible (echo still on) and force the user to wait for the echo to be set off before it would accept the password. The idea to exec getty again would involve telling login(1) which options the original getty was invoked with. It would be much easier to tell login to exit after printing "login incorrect" (and letting init re-start the getty), but then you run into the problem of the last closed process hanging up the line (if hupcl is set, which you DO normally want done) which would screw up anyone coming in through a properly set up modem (it would, of course, not affect hardwired terminals). Randy
andrew@frip.gwd.tek.com (Andrew Klossner) (12/10/87)
[]
"It would be much easier to tell login to exit after printing
"login incorrect" (and letting init re-start the getty), but
then you run into the problem of the last closed process
hanging up the line (if hupcl is set, which you DO normally
want done) which would screw up anyone coming in through a
properly set up modem (it would, of course, not affect
hardwired terminals)."
And on non-modem but shared lines, getty will reset the baud rate to
the default, so you have to cycle with the break key after every missed
password. Frustrating.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]allbery@ncoast.UUCP (Brandon Allbery) (12/10/87)
As quoted from <16848@topaz.rutgers.edu> by ron@topaz.rutgers.edu (Ron Natalie): +--------------- | No, it would be far better if getty didn't attempt to pretend | it was login at all. However, it likes to do so so it can do | things like autobauding and trying to guess what you want for | terminal modes. +--------------- So why can't getty print "Press RETURN" until it gets a recognizeable RETURN with a 1 second gap around it, then exec login with no arguments? This could be implemented now by changing only getty source (see uutty for one such PD source); "login" will work right without arguments. Then change "login" to look for a prompt in a control file of some kind. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
dcornutt@murphy.UUCP (Dave Cornutt) (12/10/87)
In article <142700007@occrsh.ATT.COM>, rjd@occrsh.ATT.COM writes: > > > > (Lots of stuff concerning the getty - login sequence) > > > > Believe me, Im a novice at this. But it occurred to me . . . > > > > Does it make sense for login, after an invalid password, to exec getty > > rather than issue its own login: prompt? This would eliminate the two > > login: prompts (surely a goodness), but would it tie login too closely > > to getty? You run into a problem with modems. If login exits, it has to close the tty fd so that getty can re-open it. This will cause modems to hang up. I suppose getty could be modified to take an arg telling it not to open the tty; instead, just use the fd that is already open. But there must be a better way... > Sounds good to me, especially for the guy who asked the original question... > To actually implement would be slightly harder, as getty expects the gettydefs > line to get the parameters to set the port to, which the login program does not > know. Maybe change both login and getty to check another file for the login > prompt and keep the sequence the same, or have just login only prompt for it > (which I see problems with), or........ EDUCATE the users to not be bothered > by it......Na, thats too easy... EDUCATE THE USERS?? Heaven forbid! What's wrong with your telepathy hardware? :-) :-) :-) Seriously, it doesn't really make sense that getty should do one thing when issuing the prompt and login do another. Actually, it doesn't make sense (at least to me) that the functions of getty and login are split among two programs. I think they should be merged into one program. What kinds of problems would this cause? Right off hand, I can't think of any, but others may know better. Comments? --- Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,uunet,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."