tags #539354 help
thanks

Hello,

As I have no clue about TTY setup, let see if I can get some other
opinions on debian-devel.

The question raised on http://bugs.debian.org/547079 is who shall be
responsible for setting up the user's tty (e.g. regarding UTF-8 handling).

Some defaults are in the kernel.
getty makes some changes, login also, and the end user may also do so in a
user profile script.

The kernel, getty, or login do not really know if the user wants a UTF-8
locale, so my preference would be to move the setup of the iutf8 tty
c_iflag to the user's configuration. For example the user could use
unicode_start / unicode_stop.

(This also has the advantage for me not to require any change in login)


The bug discusses also these alternatives:
2 iutf8 tty c_iflag forced by getty (maybe based on an option in inittab)
(currently getty always drop this flag)
3 iutf8 tty c_iflag forced by login
(I did not really understand how login shall guess when this shall be
done, maybe an option in /etc/login.defs)
4 iutf8 tty c_iflag forced by a PAM module

Do you have any opinion on how this should be done?

Thanks in advance,
--
Nekral

On Thu, Sep 17, 2009 at 08:35:16PM -0400, Mike Frysinger wrote:
> On Thursday 17 September 2009 19:59:14 Samuel Thibault wrote:
> > Mike Frysinger, le Thu 17 Sep 2009 19:30:02 -0400, a écrit :
> > > > > login/pam are there to do authentication only, not screw with the
> > > > > terminal.
> > > >
> > > > Login already does screw with the terminal in setup_tty(),
> > >
> > > presumably enough to prevent echoing of the password, but that's about it
> > > (for obvious security reasons).
> >
> > Have you looked at the code before saying that?
> >
> > /*
> > * Add your favorite terminal modes here ...
> > */
> > termio.c_lflag |= ISIG | ICANON | ECHO | ECHOE;
> > termio.c_iflag |= ICRNL;
> >
> > etc...
>
> looks like a lot of stuff login shouldnt be doing, but historically has been
> so no one complained because "it worked". extending poor behavior because
> it's already there isnt really a good line of reasoning.
>
> > > i dont have a fedora box myself, but from talking to a friend, things
> > > "just work" in the default setup. or at least it defaults everything
> > > to unicode.
> >
> > Did he check whether stty -a properly shows iutf8? Things work very
> > fine even without it, one of the very few effects of iutf8 left cleared
> > is the bug I mentioned in my report: canonical mode's treatment of
> > backspace. People rarely notice it.
>
> i didnt ask him "hey does your keyboard work", i asked him what his settings
> were after he logged in. so of course i validated the stty output.
>
> i'm not suggesting everything is great and nothing needs to be changed. i'm
> saying that login/pam is not really part of the solution.
> -mike



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100323140951.GA9223@nekral.nekral.homelinux.net" >http://lists.debian.org/20100323140951.GA9223@nekral.nekral.homelinux.net

[Nicolas François]
> As I have no clue about TTY setup, let see if I can get some other
> opinions on debian-devel.
>
> The question raised on http://bugs.debian.org/547079 is who shall be
> responsible for setting up the user's tty (e.g. regarding UTF-8 handling).

This sound related to <URL: http://bugs.debian.org/547073 >, fixed in
sysvinit. in version 2.87dsf-7. Init now leave it to the kernel to
set the utf-8 flag. Perhaps login should do the same?

I do not know much about TTY setup myself, so I do not have much to
say on the topic.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fl39zrf6q5.fsf@login1.uio.no">http://lists.debian.org/2fl39zrf6q5.fsf@login1.uio.no

Petter Reinholdtsen, le Tue 23 Mar 2010 15:33:22 +0100, a écrit :
>
> [Nicolas François]
> > As I have no clue about TTY setup, let see if I can get some other
> > opinions on debian-devel.
> >
> > The question raised on http://bugs.debian.org/547079 is who shall be
> > responsible for setting up the user's tty (e.g. regarding UTF-8 handling).
>
> This sound related to <URL: http://bugs.debian.org/547073 >, fixed in
> sysvinit. in version 2.87dsf-7. Init now leave it to the kernel to
> set the utf-8 flag. Perhaps login should do the same?

See my concern in the bug report:

“My concern is that getty used to not keep any flag at all. Keeping
_some_ flags contrary to none is not just a "fix", it's a change of
behavior. Think for instance about a situation where a user clears
the tty's iutf8. The next user to log in will have a bogus terminal
since getty would leave it cleared and nothing else will set it. This
is the same for all the flags, getty could just keep the kernel's
current state, but it doesn't. [...] Letting a user break another user's
environment is wrong�

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100323161842.GA5091@const.bordeaux.inria.fr">htt p://lists.debian.org/20100323161842.GA5091@const.bordeaux.inria.fr

Hi Samuel,

On Tue, Mar 23, 2010 at 05:18:42PM +0100, Samuel Thibault wrote:
>
> See my concern in the bug report:
>
> “My concern is that getty used to not keep any flag at all. Keeping
> _some_ flags contrary to none is not just a "fix", it's a change of
> behavior. Think for instance about a situation where a user clears
> the tty's iutf8. The next user to log in will have a bogus terminal
> since getty would leave it cleared and nothing else will set it. This
> is the same for all the flags, getty could just keep the kernel's
> current state, but it doesn't. [...] Letting a user break another user's
> environment is wrong�

Is it an issue to set the utf8 flag too often?
(does it break something?, does it affect performances?)

Also, can you elaborate on your solution. Who would configure what and how?

Best Regards,
--
Nekral


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100323225929.GE5152@nekral.nekral.homelinux.net" >http://lists.debian.org/20100323225929.GE5152@nekral.nekral.homelinux.net

Nicolas François, le Tue 23 Mar 2010 23:59:29 +0100, a écrit :
> Is it an issue to set the utf8 flag too often?
> (does it break something?,

It has the converse effect as forgetting it, cf the original bug report:

“ATM, if one runs cat from a VT with a UTF-8 locale, type a non-ascii
character, backspace, enter, the first byte of the utf-8 encoding
non-ascii will remain in the stream.�

The converse would be “with utf8 spuriously set, if one runs cat
from a VT with a non-UTF-8 locale, type a character, then a non-ascii
character, backspace, enter, the first character is dropped from the
stream�.

That's not so much a big deal (that is why nobody bothered to fix the
reported bug up to now), but it's still bogus (the other way round).

> does it affect performances?)

The performance hit is very tiny: just a couple of additional tests in
the kernel.

> Also, can you elaborate on your solution. Who would configure what and how?

I don't know enough the pam stack to know whether my solution is even
feasible. My point is that it there are at least two cases that need to
be considered:

- getty/login on a VT.
- getty/login on a serial port.

Both could be independently using utf-8 or not.

In the first case, getty could use ioctl(KDGKBMODE) to know whether the
VT keyboard is configured in UTF-8 mode or not, and set the IUTF8 flag
appropriately. That brings Linux-specific code to getty which for now
was quite OS-independent, but well.

In the second case, however, getty can not use ioctl(KDGKBMODE), since
only the other end of the serial cable knows whether it's using utf-8 or
not. The locale setting, however, has very probably been properly set
up by the user or the administrator and could be used as the source of
information for setting UTF-8 mode or not.

That is why I thought about setting it at the login/pam level, where I
believed the locale information is available, which captures both cases.

I had asked util-linux@packages.debian.org for what they think about it,
and never got an answer.

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100325132251.GG5305@const.bordeaux.inria.fr">htt p://lists.debian.org/20100325132251.GG5305@const.bordeaux.inria.fr