lamy@ai.toronto.edu (03/23/87)
Two puzzling things about 'login'. a) What on earth does it do between the time I hit return on the username line and the time it gives me back the Password prompt? Can't it turn echoing off right away so that when I am in a hurry the first few characters of my password don't end up on the screen? Why do these characters get ignored? (This occurs on lightly loaded Vax 780 running Berkeley 4.2 and Sun 3 under 3.2). Scream as you like against VMS, it does typeahead the way it ought to be done (i.e. the way I like it :-) b) Any fundamental reason why true baud rate detection is not provided? Sure sounds like "lets cycle through speeds for now -- we'll fix that later"... Jean-Francois Lamy lamy@ai.toronto.edu (CSNet, UUCP) AI Group, Dept of Computer Science, lamy@ai.toronto.cdn (EAN) University of Toronto, Ont, Canada M5S 1A4 lamy@ai.utoronto (Bitnet)
chris@mimsy.UUCP (03/30/87)
In article <8703231450.AA18626@ephemeral.ai.toronto.edu> lamy@ai.toronto.edu writes: >a) What on earth does [login] do between the time I hit return on > the username line and the time it gives me back the Password prompt? That is not login, but rather getty, that you are running. It is exec'ing login. >b) Any fundamental reason why true baud rate detection is not provided? It *is* provided---you just have to know who to ask. :-) RCS file: RCS/subr.c,v retrieving revision 1.1 diff -c2 -r1.1 subr.c *** /tmp/,RCSt1003237 Sun Mar 29 20:30:25 1987 --- subr.c Sat Oct 5 06:40:21 1985 *************** *** 417,420 **** --- 417,422 ---- } + #ifdef notdef + /* * This auto-baud speed select mechanism is written for the Micom 600 *************** *** 469,470 **** --- 471,608 ---- return (type); } + + #else + + /* + * Try to figure out what speed the terminal is set to based on what + * a carriage-return or newline looks like at 2400 baud. 5/18/82 FLB + * + * N.B.: some of the table entries for \n collide with those for \r. + * Only the first one in the table will be matched. + */ + + #include <sys/types.h> + #include <sys/time.h> + #include <signal.h> + #include <setjmp.h> + + struct autobaud { + char *s_speed; + char *s_string; /* first byte is length */ + } a_tab[] = { + /* carriage-return */ + "110-baud", "\3\000\000\000", /* also \n */ + "300-baud", "\3\200\200\000", /* collides with 600 \n */ + "300-baud", "\3\200\000\000", + "300-baud", "\3\000\200\000", /* also \n */ + "600-baud", "\3\000\376\000", + "1200-baud", "\2\346\200", + "1200-baud", "\2\346\340", + "1200-baud", "\2\367\300", + "1800-baud", "\2\000\376", /* also \n */ + "1800-baud", "\2\000\377", + "2400-baud", "\1\015", + "2400-baud", "\1\215", + "4800-baud", "\1\361", /* needed for Gandalf */ + "4800-baud", "\1\362", + "4800-baud", "\1\363", /* needed for Gandalf */ + "4800-baud", "\1\371", /* needed for Gandalf */ + "4800-baud", "\1\375", /* needed for Gandalf */ + "4800-baud", "\1\376", /* needed for Gandalf; + collides with 9600 \n */ + "9600-baud", "\1\377", /* needed for Gandalf */ + + /* newline */ + "600-baud", "\3\200\000\000", /* collides with 300 \r */ + "1200-baud", "\2\230\200", + "2400-baud", "\1\012", + "4800-baud", "\1\370", + "9600-baud", "\1\376", /* collides with 4800 \r */ + + /* The next entry must be the last entry in the table. */ + 0, "\1\0", /* BREAK: handled specially */ + + 0, 0 + }; + + char * + autobaud() + { + register struct autobaud *tp; + register int i; + struct sgttyb ttyb; + static char buf[10]; + + extern jmp_buf timeout; /* from main.c */ + extern int dingdong(); /* from main.c */ + + if (TO) { + if (setjmp(timeout)) { + /* + * Drop DTR for a while. This is important + * for Gandalf lines which must be told to + * disconnect. + */ + ttyb.sg_ispeed = ttyb.sg_ospeed = 0; + (void) ioctl(0, TIOCSETP, &ttyb); + sleep(3); + exit(1); + } + signal(SIGALRM, dingdong); + alarm(TO); + } + + /* + * The following hack sets BREAK to sequence to the next + * gettytab entry. + */ + a_tab[(sizeof (a_tab) / sizeof (a_tab[0])) - 2].s_speed = + NX && *NX ? NX : 0; + + ttyb.sg_ispeed = ttyb.sg_ospeed = B2400; + ttyb.sg_flags = ANYP|RAW; + + for (;;) { + (void) ioctl(0, TIOCSETP, &ttyb); + input(buf, sizeof buf); + + for (tp = a_tab; tp->s_speed; tp++) { + for (i = 0;; i++) { + if (buf[i] != tp->s_string[i]) + break; + if (i == buf[0]) { + alarm(0); + return (tp->s_speed); + } + } + } + } + /*NOTREACHED*/ + } + + input(s, n) + char *s; + register int n; + { + register char *cp = s + 1; + fd_set rfds; + struct timeval timeout; + + FD_ZERO(&rfds); + FD_SET(0, &rfds); + timeout.tv_sec = 0; /* .15 seconds */ + timeout.tv_usec = 150000; + n--; /* first byte is for length */ + (void) read(0, cp, 1); /* wait for something */ + n--, cp++; + while (--n >= 0) { + if (select(1, &rfds, (fd_set *)0, (fd_set *)0, &timeout) <= 0) + break; + if (read(0, cp, 1) != 1) + break; + cp++; + } + *s = (cp - s) - 1; + } + + #endif -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
pavlov@hscfvax.UUCP (03/30/87)
In article <8703231450.AA18626@ephemeral.ai.toronto.edu>, lamy@ai.toronto.edu writes: > Two puzzling things about 'login'. > a) What on earth does it do between the time I hit return on the username line > and the time it gives me back the Password prompt? ....... getty prompts you for username; login prompts for password (unless name is messed up...)
ccplumb@watnot.UUCP (03/30/87)
In article <8703231450.AA18626@ephemeral.ai.toronto.edu> lamy@ai.toronto.edu writes: >Two puzzling things about 'login'. I know the answer to one.. >a) What on earth does it do between the time I hit return on the username line > and the time it gives me back the Password prompt? Can't it turn echoing > off right away so that when I am in a hurry the first few characters of > my password don't end up on the screen? It still has to read the /etc/passwd entry. If the password field is null, it doesn't ask for a password. Thus, the delay. (Do you have a `who' login?) -- -Colin Plumb (watmath!watnot!ccplumb) Silly quote: The early bird will find his can of worms.
guy@gorodish.UUCP (03/30/87)
>Two puzzling things about 'login'. >a) What on earth does it do between the time I hit return on the username line > and the time it gives me back the Password prompt? If you've just dialed up the system, it's not "login" you type your username to, it's "getty", and what it's doing is (among other things) running "login". > Can't it turn echoing off right away so that when I am in a hurry the > first few characters of my password don't end up on the screen? Maybe, but this would cause odd behavior if you didn't have a password and typed commands ahead (but then again, you should always have a password if you don't have a very restricted login shell). Also, note that the 4.2 version of "getty" can be configured so that it runs some program other than "login" after it gets the username; those programs would have to understand that echoing is turned off when they are started. > Why do these characters get ignored? Because "getty" normally runs in RAW mode, while the password is collected in cooked mode. When you switch to or from RAW mode, unread input is discarded. >b) Any fundamental reason why true baud rate detection is not provided? > Sure sounds like "lets cycle through speeds for now -- we'll fix that > later"... If by "true baud rate detection" you mean autobauding, where you type something like CR at the system and it figures out the baud rate from what the CR appeared as, the reason it's not provided may be that your system administrator didn't set it up. It appears to be provided by "getty", although for some unknown reason it isn't documented in the 4.3 manual page. The comment in the code says * This auto-baud speed select mechanism is written for the Micom 600 * portselector. Selection is done by looking at how the character '\r' * is garbled at the different speeds. and it attempts to distinguish between 300 baud, 1200 baud, 2400 baud, 4800 baud, and 9600 baud. If you set up a port as an auto-baud port, by specifying the "Auto-baud" entry as the "gettytab" entry for that port, it will wait for a CR and then select one of "300-baud", "1200-baud", "2400-baud", "4800-baud", or "9600-baud" as the entry for that port. It also claims to support a Develcon port selector (according to the comments - the manual page says a MICOM port selector) which will send a baud rate string at a predefined baud rate. This can be selected by the "DSW" entry; it will select one of "std.110", "std.134", "std.150", ... "std.19200" based on the message. I haven't tried any of this, so I don't know if it really works.
bill@westpt.UUCP (03/31/87)
In article <15831@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > Can't it turn echoing off right away so that when I am in a hurry the > > first few characters of my password don't end up on the screen? > > > > Why do these characters get ignored? > > Because "getty" normally runs in RAW mode, while the password is > collected in cooked mode. When you switch to or from RAW mode, > unread input is discarded. > Actually what is happening is the password is taken in using a call to the routine getpass() which reads directly from /dev/tty and not from the stdin. So anything you typed before getting the Password: prompt went to the stdin and is not available to that call. I can only assume this was done to prevent anyone from spoofing login as to who is really there. The echo goes away because reading from /dev/tty has nothing to do with the current settings of stty. Another catch to this method is reads and writes to/from /dev/tty cannot be redirected. UUCP: {philabs,phri}!westpt!bill PHONE: (914)446-7747 US SNAIL: Martin Marietta Data Systems RADIO: KB3YV USMA, Bldg 600, Room 26 AX.25 KB3YV @ WA2RKN West Point, NY 10996
muller@sdcc7.UUCP (04/01/87)
I have used the develcon part and it works just fine. Keith Muller University of California, San Diego
capshaw@milano.UUCP (04/02/87)
Re: slow login Since Sun release 3.0 our host setup procedure includes replacing /usr/ucb/quota with /bin/true. At the time this removed a terrible delay that otherwise occured during login. I don't know if this is still necessary. -- Dave Capshaw
kurt@hi.UUCP (04/02/87)
In article <4277@milano.UUCP> capshaw@milano.UUCP writes: >Re: slow login > >Since Sun release 3.0 our host setup procedure includes replacing >/usr/ucb/quota with /bin/true. At the time this removed a terrible >delay that otherwise occured during login. I don't know if this is >still necessary. > >-- >Dave Capshaw On a SUN3/160 running SUN 3.3 with QUOTAS compiled in but not used (at least for now): 1000 * /usr/ucb/quota: 492.1 real 43.4 user 158.5 sys 1000 * /bin/true: 268.0 real* 37.5 user 63.1 sys The overhead of the loop (done is csh) should be minimal. * we were running with a high load tonight. -- Kurt Zeilenga (zeilenga@hc.dspo.gov)
guy@gorodish.UUCP (04/02/87)
>Actually what is happening is the password is taken in using a call to >the routine getpass() which reads directly from /dev/tty and not from >the stdin. So anything you typed before getting the Password: prompt >went to the stdin and is not available to that call. Excuse me? "/dev/tty" is just an indirect device that refers to a process' controlling terminal. That terminal is also the standard input for "getty" and "login". The explanation above is completely bogus; anything you type before getting the Password: prompt most definitely *would* be available, were it not for the flush caused by switching from RAW to non-RAW mode. >The echo goes away because reading from /dev/tty has nothing to do >with the current settings of stty. You wanna bet? Reading from "/dev/tty", since it's just an indirect device referring to the controlling terminal, most definitely *does* have something to do with the current mode settings on the controlling terminal. Try it! >Another catch to this method is reads and writes to/from /dev/tty cannot >be redirected. That's one reason why "/dev/tty" is there! Programs - such as programs that read passwords - may want to guarantee that they'll read from the process' controlling terminal even if their standard input has been redirected away from that terminal.
david@elroy.UUCP (04/03/87)
In article <4277@milano.UUCP>, capshaw@milano.UUCP writes: > Re: slow login > Since Sun release 3.0 our host setup procedure includes replacing > /usr/ucb/quota with /bin/true. At the time this removed a terrible > delay that otherwise occured during login. I don't know if this is > still necessary. This was fixed in 3.2. The problem was that /usr/ucb/quota was checking the users quota on *ALL* filesystems even if they were mounted with the noquota option. This was especially bad if a NFS server (or two) was down and it had to wait until a timeout. If you are running 3.2 or later and don't care about quotas, be sure to mount everything with the noquota option. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov (new) seismo!cit-vax!elroy!david UUCP Disclaimer: No one listens to me anyway!
gwyn@brl-smoke.UUCP (04/03/87)
In article <553@westpt.usma.edu> bill@westpt.usma.edu (Bill Gunshannon) writes: >In article <15831@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: >... >Actually what is happening is ... Before contradicting Guy Harris, you should be sure you know what you're talking about, which in this case you didn't. Guy was right, and you were wrong. There is a single character queue per terminal (not counting multiplexing, which is a different topic), and all that /dev/tty is is a canonical entry to the controlling terminal's data queue. "stdin" is actually not anything magic at all but is just the STDIO buffered I/O library's name for its way of getting at file descriptor 0, which has been opened on the specific /dev/tty* then shared across the various getty/login/shell transitions. Unless there has been an I/O redirection (which involves closing the f.d. and opening it on a different inode) or a change of controlling terminal (rare except in job-control shells), /dev/tty will access the same data queues as f.d.s 0, 1, and 2. Do the following experiment: $ cat </dev/tty & Then type in various shell commands, e.g. "ls", "echo hi", etc. The shell (which has reprompted) and the "cat" process will fight over your terminal input, which will end up going to whoever gets it first. (Type a couple of stream delimiters, usually ^D, to get out of this funny state.)
richl@penguin.UUCP (04/03/87)
In article <553@westpt.usma.edu> bill@westpt.usma.edu (Bill Gunshannon) writes: | Actually what is happening is the password is taken in using a call to | the routine getpass() which reads directly from /dev/tty and not from | the stdin. So anything you typed before getting the Password: prompt | went to the stdin and is not available to that call. I can only assume | this was done to prevent anyone from spoofing login as to who is really | there. The echo goes away because reading from /dev/tty has nothing to do | with the current settings of stty. Some sort of urban myth being spouted here ... when /dev/tty and stdin ARE the same, as during login, reading from either one gets you the same input. Echo is not there because it is explicitly turned off, not because you are reading from /dev/tty. Lastly, input is flushed, as Guy said, because you are changing settings on the terminal. In case there is any question ... this information from direct reading of the source for getpass() and a simple test program which sleeps 5 seconds, opens /dev/tty, and reads one line. You may type all you want, but the first read from /dev/tty will return the very first line you typed -- even though you typed it before it was opened. Rick Lindsley
cs490147@umbc3.UUCP (04/16/87)
At the time of loging in the fact remains transparent to the user that
the program asking for the "login:" prompt is actually NOT the login
program but a program called getty. This getty exec's login and the
user then is prompted with "passwd:". The program getty originally
gets invoked by another program called init (which is kind of special)
So, I guess you have got to be a little patient and wait for the login
program to get started .... and then you will be rolling !
Dipto Chakravarty