Bug#221290: [OBORONA-SPAM] [?? Probable Spam] Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Hello, first of all, I found out, that if I enter a sane login name (does not need to exist) and press enter twice, then I can safely enter umlauts, even delete them (no visual artefacts) and everything is fine after login. So only the first call to getty is vulnerable to this effect. If I exceed the maximum number of tries, the next getty is back to the old behaviour, with visual artefacts and so on. On Thu, Sep 29, 2005 at 12:52:47AM +0300, Alexander Gattin wrote: On Wed, Sep 28, 2005 at 10:46:23PM +0200, Helge Kreutzmann wrote: Hello Alexander, On Wed, Sep 28, 2005 at 10:48:46PM +0300, Alexander Gattin wrote: After a small, fast and simple check I conclude that the issue with setting cs7 on terminal after entering Probably istrip (clear 8th bit of input characters) is more relevant to the problem than cs7... I'm not a TTY guru. Yes. I know this from a different bug still present in the BTS, where I have to manually set -istrip. I have prepared a wrapper script, to work around the problem with getty. Currently it just sets tty to some 'sane' state. Citing /root/stty-cs8-login.sh: #!/bin/bash --norc stty cs8 -parenb -parodd -cstopb -inpck -istrip exec /bin/login $@ Please, try it to see whether it fixes your problem or not. The script should be given to getty instead It works as intended. The visual artefact on the first prompt remains, of course, but the shell behaves as expected (i.e., vim behaves correctly). So I guess the next step would be to find out where the default settings are stored, so that the wrapper could retrieve the default set instead of hard coded corrections? Intrinsics are very simple, indeed :) -- getty prints /etc/issue and login: prompt after that. Yep, reading the man page of getty helps (I thought I had to read some scripts of sources) So this testing clearly shows that this is a getty issue. Getty sees the 8 bit character and decides, to change the tty-settings accordingly (for some reason). It only runs this detection on the first login-prompt displayed by itself. A side effect is the distorted printing of the backspace operation. Should we reassign to getty? Greetings Helge -- Dr. Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferred 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software libre: http://www.ffii.de/ pgp54yVkS76hp.pgp Description: PGP signature
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Anyway this is more general problem but not shadow bug (it is about UTF8 support, not about umlauts), so probably nothing should be done in shadow. But some program should set that flag *before* login run and *all* terminal emulators should set this flag when run in UTF-8 locale :( The discussion is going way over my head but I think this last paragraph just shows that I should actually either close this bug...or reassign it to a package.but which? no-one exactly knows...:-) Right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
28 вересня 2005 о 06:46 +0200 Christian Perrier написав(-ла): Anyway this is more general problem but not shadow bug (it is about UTF8 support, not about umlauts), so probably nothing should be done in shadow. But some program should set that flag *before* login run and *all* terminal emulators should set this flag when run in UTF-8 locale :( The discussion is going way over my head but I think this last paragraph just shows that I should actually either close this bug...or reassign it to a package.but which? no-one exactly knows...:-) This is a different bug. Original bug report was about umlauts in non-utf8 locale and is also reproducible. Bug about UTF-8 locales should be probably cloned and reassigned to console-tools or kbd. -- Eugeniy Meshcheryakov Kyiv National Taras Shevchenko University Information and Computing Centre http://icc.univ.kiev.ua signature.asc Description: Digital signature
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
On Tue, 27 Sep 2005, Eugeniy Meshcheryakov wrote: 27 вересня 2005 о 18:36 +0200 Tomasz Kłoczko написав(-ла): Eugeniy this is incorrect way .. better will be use IUTF8 atribute I know that it is incorrect, i sent this patch only as demonstration of the problem. from tty level description. Example from my system: $ stty -a | grep utf -iuclc ixany imaxbel -iutf8 Not in Debian. $ stty -a | grep utf8 $ So probably will be good add for Debian coreutils patch for allow display/set/unset IUTF8 bit. Why this is better ? Because termios is more generic and using nl_langinfo() requires LOCALE database in system which does not exist usualy in embeded systems (because it is very huge and full i18n support isn't neccessary on this kind instalations). Also reading current LOCALE settings it not the same as reading terminal capabilities (IIRC setlocale() also changes tty atributes .. if not this is next thing for fix :). no, setlocale do not change tty attributes and it must not. If someone want use UFT-8 encoding and console works in diffrent way if UF-8 is used so probably will be good add enable IUTF8 bit in setlocale(). By default linux console device have UTF-8 support enabled. Also current Wrong, it does not. Yes. You are right (incorrect interpretation stty output). Sorry. glibc provides IUTF8 bit mask for reading this atribute (look at bits/termios.h) .. so all around is ready. Only IUTF8 atribute must be Yes it provides it but it is not documented. correctly readed and used .. nothing more. Of cource also it will be good As I wrote it does not set by default. Be it set we'll haven't this problem. if stty comand will correctly report IUTF8 :) (I don't know is attached patch which bases on SuSE patch is used in Debian coreutils). Anyway this is more general problem but not shadow bug (it is about UTF8 support, not about umlauts), so probably nothing should be done in shadow. But some program should set that flag *before* login run and *all* terminal emulators should set this flag when run in UTF-8 locale :( Probably good candidat will be getty for enable IUTF8 bit. Also I'm check xterm. For me something is wrong because stty on xterm allways report IUTF8 is set (never mind is -u8 or +u8 options is used). kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Hello Christian, On Wed, Sep 28, 2005 at 06:46:16AM +0200, Christian Perrier wrote: Anyway this is more general problem but not shadow bug (it is about UTF8 support, not about umlauts), so probably nothing should be done in Well, I think there are two issues here: one about UTF8 support which was brought up by you on April 13th any my issue, with has nothing to do with all caps and backspace erases prompt and UTF8, but with umlauts the effect, that erasing umlauts changes the terminal settings as clearly shown in my recent comparison of ssty -a output with and without the wrong sequence. You state, that without UTF 8 everything is fine. So you don't experience any problem using the sequence I stated in my recent reply in a non-UTF8 console (i.e., on a virtual text console with has not been switched to UTF8)? Did you try launching vim after using the sequence? Did you compare the output of stty -a Maybe we should clone this bug, one for the UFT8 issue (where a patch has been proposed already) and one for my issue? shadow. But some program should set that flag *before* login run and *all* terminal emulators should set this flag when run in UTF-8 locale :( The discussion is going way over my head but I think this last paragraph just shows that I should actually either close this bug...or reassign it to a package.but which? no-one exactly knows...:-) Please do not close (I will reopen). I can reproduce my bug very clearly (on alpha, amd64 and ppc (see below)). Somewhere in the login code the sequence Umlaut backspace does change the terminal settings as shown above. I just checked, also my ibook (ppc, using framebuffer) is affected (funnily, the first console is broken in respect to display of umlauts, and there the error does not occur, but this is not the part of the bug). If you need more people to test, I can ask a friend of my, who administers many machines. Right? No. Please tag it help if you do not know the cause. I tried to have a look at the sources, but frankly I don't know how login sets console properties, hence I did not find the problematic point. Greetings Helge -- Dr. Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferred 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software libre: http://www.ffii.de/ pgp56oPlCN6Wk.pgp Description: PGP signature
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
tags 221290 confirmed thanks On Tue, Sep 27, 2005 at 06:13:25PM +0200, Helge Kreutzmann wrote: Well, I don't have an all caps afterwards. Surely, that's completely another thing, for historical reasons BTW. I just checked (on Sarge) the same, on linux console, vesafb, UA/UTF-8 keymap When I run stty -a in a clean shell vs. in a broken shell (in the sequence above, before running reset) I get the following differences: claen:broken: ===== -parenb -parodd cs8 parenb -parodd cs7 -inpck -istripinpck istrip the same, but sometimes only cs8 vs. cs7 difference is noticed... :-/ If you need more/other info, please tell me which. Thanks for your patience, anyway. Also, I strongly suspect that the bug is in _getty_ package, because IIRC login: prompt is printed/processed by getty, and passwd: one is provided by login later. And I do not recall any messing with stty there... -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Right? No. Please tag it help if you do not know the cause. I tried to have a look at the sources, but frankly I don't know how login sets console properties, hence I did not find the problematic point. Well, it seems that my co-maintainers have a better idea than me about this problem. So, let just them deal with it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221290: [OBORONA-SPAM] [?? Probable Spam] Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Hi! After a small, fast and simple check I conclude that the issue with setting cs7 on terminal after entering non-ascii letters into login: prompt is really a probem with /sbin/getty (util-linux pkg). On Wed, Sep 28, 2005 at 07:49:14PM +0300, Alexander Gattin wrote: When I run stty -a in a clean shell vs. in a broken shell (in the sequence above, before running reset) I get the following differences: claen:broken: ===== -parenb -parodd cs8 parenb -parodd cs7 -inpck -istripinpck istrip the same, but sometimes only cs8 vs. cs7 difference is noticed... :-/ If you need more/other info, please tell me which. Thanks for your patience, anyway. Also, I strongly suspect that the bug is in _getty_ package, because IIRC login: prompt is printed/processed by getty, and passwd: one is provided by login later. Steps that I took in order to check the issue: 1) created an executable script /root/stty.sh: #!/bin/sh stty -a 2) added new getty instance on tty8 to /etc/inittab: 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6 +8:23:respawn:/sbin/getty -l /root/stty.sh 38400 tty8 3) signalled init: cherokee:~# telinit q After this I switch to tty8 and can play entering different login names onto login: prompt and seeing what `stty -a` tells me, immediately. Helge, I suggest you to repeat the same trick and see that getty indeed messes with tty settings. ;) And I do not recall any messing with stty there... I mean I don't remember anything of that kind in login, and unsurprisingly `man getty` says the next: getty has several non-standard features that are useful for hard-wired and for dial-in lines: o Adapts the tty settings to parity bits and to erase, kill, end- of-line and uppercase characters when it reads a login name. The program can handle 7-bit characters with even, odd, none or space parity, and 8-bit characters with no parity. P.S. so if nobody objects, I'll reassign the bug to util-linux soon. Eugene: there were talks about utf8 and my issues, sence of which I completely missed... Do you agree that this particular bug is about getty/cs7? -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221290: [OBORONA-SPAM] [?? Probable Spam] Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Hello Alexander, On Wed, Sep 28, 2005 at 10:48:46PM +0300, Alexander Gattin wrote: After a small, fast and simple check I conclude that the issue with setting cs7 on terminal after entering non-ascii letters into login: prompt is really a probem with /sbin/getty (util-linux pkg). Confirmed (but see below). On Wed, Sep 28, 2005 at 07:49:14PM +0300, Alexander Gattin wrote: Steps that I took in order to check the issue: 1) created an executable script /root/stty.sh: After this I switch to tty8 and can play entering different login names onto login: prompt and seeing what `stty -a` tells me, immediately. Yes, on a quick look (I will do more tomorrow) I see how Umlaute change the stty settings. But there is a notable difference: If I enter ä Enter ä on un normal login, the second ä is changed to d. On the prepared terminal, however, this is not the case. What I do see is, that: ä Backspace Enter b Enter still has cs7, while skipping the backspace, i.e. ä Enter b Enter I get cs8. So obviously the combination of ä and backspace is rememberd by getty, while single umlaute are forgotten on the next login prompt. On the normal login, the effect is, however, the same. P.S. so if nobody objects, I'll reassign the bug to util-linux soon. I don't understand the intrinsics of the login-getty interaction, but this makes sense to me. Greetings Helge -- Dr. Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferred 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software libre: http://www.ffii.de/ pgpbJrPOZ4Uqr.pgp Description: PGP signature
Bug#221290: [OBORONA-SPAM] [?? Probable Spam] Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
Hi! On Wed, Sep 28, 2005 at 10:46:23PM +0200, Helge Kreutzmann wrote: Hello Alexander, On Wed, Sep 28, 2005 at 10:48:46PM +0300, Alexander Gattin wrote: After a small, fast and simple check I conclude that the issue with setting cs7 on terminal after entering Probably istrip (clear 8th bit of input characters) is more relevant to the problem than cs7... I'm not a TTY guru. Yes, on a quick look (I will do more tomorrow) I see how Umlaute change the stty settings. But there is a notable difference: If I enter ä Enter ä on un normal login, the second ä is changed to d. On the prepared terminal, however, this is not the case. Sorry, I can't test with umlautes, because I don't have a German keymap and even having it I would not know how to compose or enter an umlaute anyway... What I do see is, that: ä Backspace Enter b Enter still has cs7, while skipping the backspace, i.e. ä Enter b Enter I get cs8. What I see with Ukrainian letters is that with different letters I get different tty settings, sometimes istrip, sometimes -istrip. Sometimes parenb, sometimes without it and so on. So obviously the combination of ä and backspace is rememberd by getty, while single umlaute are forgotten on the next login prompt. On the normal login, the effect is, however, the same. I have prepared a wrapper script, to work around the problem with getty. Currently it just sets tty to some 'sane' state. Citing /root/stty-cs8-login.sh: #!/bin/bash --norc stty cs8 -parenb -parodd -cstopb -inpck -istrip exec /bin/login $@ Please, try it to see whether it fixes your problem or not. The script should be given to getty instead of real login binary (in /etc/initab file): 9:23:respawn:/sbin/getty -l /root/stty-cs8-login.sh 38400 tty9 After editing /etc/initab run `telinit q` and you will be able to login on 9th virtual console using sanitized stty settings. P.S. so if nobody objects, I'll reassign the bug to util-linux soon. I don't understand the intrinsics of the login-getty interaction, but this makes sense to me. Intrinsics are very simple, indeed :) -- getty prints /etc/issue and login: prompt after that. When getty has got a username there, it just exec's `/bin/login -- username` so that login binary gets username as 2nd argument and doesn't ask for it anymore, instead prompts for password and voila. P.S. Of course, login has its own login: prompt but it's intentionally made identical to the one of getty. -- WBR, xrgtn
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
On Tue, 27 Sep 2005, Eugeniy Meshcheryakov wrote:
27 вересня 2005 о 07:38 +0200 Christian Perrier написав(-ла):
I was waiting for upstream resync to deal with this bug report but it
still seems to be here.
When entering high-ascii characters at the login prompt (usually by
mistake), such as é, and then hitting Backspace to remove them,
they're not erased at the prompt...and, when entering the correct
login and validating, login switched the terminal to all-caps.
You can switch terminal to all-caps more easyly: just enter you login in
all-caps and then password as usual. So, I think it (all-caps) is normal
behavior (for historic reasons probably).
This happens in the Linux console. Nothing bad happens in a terminal,
eitheer UTF-8 or ISO
Because terminal you have used do not support all-caps mode ;)
I tried to look at problem with erasing of characters and found that
kernel uses undocumented (in termios(3)) flag IUTF8. If this flag is not
set kernel tty driver will interpret characters as single-byte. So some
program should set this flag when terminal is in UTF8 mode...
Attached patch fixes this problem for 'login' when it run under UTF-8
locale. But on usual system it is run under C locale :(. So, I think
some other program should do this (console-tools/kbd?), but this will
not fix problem for terminal emulators :(.
Eugeniy this is incorrect way .. better will be use IUTF8 atribute
from tty level description. Example from my system:
$ stty -a | grep utf
-iuclc ixany imaxbel -iutf8
Why this is better ? Because termios is more generic and using
nl_langinfo() requires LOCALE database in system which does not exist
usualy in embeded systems (because it is very huge and full i18n support
isn't neccessary on this kind instalations).
Also reading current LOCALE settings it not the same as reading terminal
capabilities (IIRC setlocale() also changes tty atributes .. if not this
is next thing for fix :).
By default linux console device have UTF-8 support enabled. Also current
glibc provides IUTF8 bit mask for reading this atribute (look at
bits/termios.h) .. so all around is ready. Only IUTF8 atribute must be
correctly readed and used .. nothing more. Of cource also it will be good
if stty comand will correctly report IUTF8 :) (I don't know is attached
patch which bases on SuSE patch is used in Debian coreutils).
IMO problem is for fix in shadow 4.0.14. Before will be good send
broadcast message to FC, Mandriva, Gentoo and other main distribution
maintainers with call for patching coreutils (attached patch bases on SuSE
fix). Also it will be good inform coreutils maintainer for commit attached
patch in next coreutils release (anyone have good contact with coreutils
maintainer ?).
On release shadow 4.0.13 I'll add TODO entry with short description about
plan use IUTF8 tty atribute in login.
kloczek
--
---
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
---
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]--- coreutils-5.2.1//src/stty.c
+++ coreutils-5.2.1//src/stty.c
@@ -232,6 +232,9 @@
#ifdef IMAXBEL
{imaxbel, input, SANE_SET | REV, IMAXBEL, 0},
#endif
+#ifdef IUTF8
+ {iutf8, input, SANE_UNSET | REV, IUTF8, 0},
+#endif
{opost, output, SANE_SET | REV, OPOST, 0},
#ifdef OLCUC
@@ -581,6 +584,9 @@
[-]istrip clear high (8th) bit of input characters\n\
), stdout);
fputs (_(\
+ * [-]iutf8 assume UTF-8 encoding\n\
+), stdout);
+ fputs (_(\
* [-]iuclc translate uppercase characters to lowercase\n\
* [-]ixany let any character restart output, not only start character\n\
[-]ixoff enable sending of start/stop characters\n\
@@ -682,7 +688,7 @@
-raw same as cooked\n\
), stdout);
fputs (_(\
- sane same as cread -ignbrk brkint -inlcr -igncr icrnl\n\
+ sane same as cread -ignbrk brkint -inlcr -igncr icrnl -iutf8\n\
-ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr\n\
-onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0\n\
isig icanon iexten echo echoe echok -echonl -noflsh\n\
Bug#221290: [Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt
27 вересня 2005 о 18:36 +0200 Tomasz Kłoczko написав(-ла): Eugeniy this is incorrect way .. better will be use IUTF8 atribute I know that it is incorrect, i sent this patch only as demonstration of the problem. from tty level description. Example from my system: $ stty -a | grep utf -iuclc ixany imaxbel -iutf8 Not in Debian. $ stty -a | grep utf8 $ Why this is better ? Because termios is more generic and using nl_langinfo() requires LOCALE database in system which does not exist usualy in embeded systems (because it is very huge and full i18n support isn't neccessary on this kind instalations). Also reading current LOCALE settings it not the same as reading terminal capabilities (IIRC setlocale() also changes tty atributes .. if not this is next thing for fix :). no, setlocale do not change tty attributes and it must not. By default linux console device have UTF-8 support enabled. Also current Wrong, it does not. glibc provides IUTF8 bit mask for reading this atribute (look at bits/termios.h) .. so all around is ready. Only IUTF8 atribute must be Yes it provides it but it is not documented. correctly readed and used .. nothing more. Of cource also it will be good As I wrote it does not set by default. Be it set we'll haven't this problem. if stty comand will correctly report IUTF8 :) (I don't know is attached patch which bases on SuSE patch is used in Debian coreutils). Anyway this is more general problem but not shadow bug (it is about UTF8 support, not about umlauts), so probably nothing should be done in shadow. But some program should set that flag *before* login run and *all* terminal emulators should set this flag when run in UTF-8 locale :( /me hates Linux console system -- Eugeniy Meshcheryakov Kyiv National Taras Shevchenko University Information and Computing Centre http://icc.univ.kiev.ua signature.asc Description: Digital signature
