On Thu, Aug 04, 2016 at 03:47:19AM +0300, Dmitry Bogatov wrote: > > > > > When trying to login with fgetty, I could read my password on the > > > > screen while typing. Did not continue. > > > > ngetty + login behaves good > > > > ngetty + login1 will get in well, but no key press will echo on the > > > > console. > > > > > > Sorry, I assumed you read C. This is intended behaviour. Please, > > > continue and tell, whether rest is OK. I expect terminal to be not in > > > good shape, but after `reset` I expect fancy letter to work. > > > > fgetty_patched + login1: ? doesn't show up, (arg: 1) instead, even after > > reset. > > > > ngetty + login1: no letter will show up after logging in, but they are > > there (except ?); that is, if I (blindly) type > > I am almost out of ideas. Let me sum all we have done: > > - problem raises in /bin/bash and /usr/bin/rc, but not in /bin/sh.
That is correct. Also, I have installed csh, which depends on libbsd0 and libc6, and I can type my beloved word "ñandú". But, this is new, tcsh, which depends on libtinfo5 produces this: ~> echo \303\261and\303\272 ~> ñandú > Noteworthy, that /bin/sh does not link to libreadline. No, it links to dash(1), which depends on libc6 only. > - problem still present, even if we remove every terminal-manipulation > code from fgetty, login1, login2 It seems so. > - problem happens with root and non-root logins That's correct. It doesn't matter the priviledge that the user has. > - problem disappear in child process, and this child process have a bit > different terminal configuration: -isig vs isig OK, I suppose so. > - problem happens without fgetty binary, with only login1 and login2. That is correct. I tested login1 by configuring: # /etc/inittab: 5:23:respawn:/sbin/ngetty tty5 6:23:respawn:/sbin/ngetty tty6 # /etc/ngetty/Conf: Password: # options format: # [ttyX]=option[=value] #=debug =environ=,TERM=linux tty5=echo-off tty5=login-prog=/lib/fgetty/login1 tty5 will behave the same as tty4 (ngetty will behave as bad as fgetty when using login1). > - `reset' does not help I think that reset did something by applying the patch. I can look again. > > Please, do following things: > > - set emacs (or anything that is interactive and does not link > readline) as login shell and tell, whether bug arises OK. I will try with ed. > - since you said that good shell and bad shell differs in terminal > configuration, use `stty(1)' to configure bad shell as good one, > and via-verse. OK. I will be back to you with these testings. > - replace login1 with following shell script (extremely insecure, > do not forget to revert) > #!/bin/bash > /bin/bash > and test following cases: > + ngetty with such login1 > + fgetty with such login1 > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io
