Keyboard suddenly stops reacting on login screen

[E. Lurquin]

Binary package hint: gdm

In Hardy (was ok in Gutsy and previous releases) with gdm 2.20.x, if VTAllocation=false in gdm.conf (i.e. to allow to run a permanent Xvfb server for several days or at least enough time to fix heavy bugs in a user's profile while letting the user work paralelly on it's normal display), at GDM startup in the middle of the boot sequence, display :0 starts on tty1 (or 2, I don't remember) instead of tty7, leaving the user just the time to type half of his password, then the keyboard suddenly stops responding while the mouse continues to behave gently on the greeter (login) screen.

I suspect that the reason for this is that the boot sequence reaches its end and that a getty spawned (so late, why ?) on the same tty1 (or 2), so that, now, all the keystrokes silently end up on the hidden tty (actually, if you switch vt, using chvt being logged from another host, you can even see them written on the dumb tty, including his password, of course, in white on black ;-)

The solution is pretty obvious: put VTAllocation=true again in gdm.conf and stop using Xvfb if you did (there are anyway other means to graphically work on a user's workstation while letting the user work as well at the same time) or write an XVfb wrapper which ignores the 'vt 0x' options and pass the other options to Xvfb.real.

I filed a bug upstream requesting that 'vt xy' is not inserted anymore on command lines of Xvfb servers, whatever the value of VTAllocation would be, so that one can keep this option to true even when one wishes to temporarily use an Xvfb server: this is 538625. But, anyway, I thought I'll share this issue with you as well because the symptoms are highly surprising, and it looks like there are a lot of reports of keyboards not responding, which might be related (why not do an openvt of tty1 to 6 very early in the boot sequence, even if getty's start later, so that one is sure about the absence of conflicts in tty allocation ?)

Just in case, I tag this as a security issue, because it allows with an easy manipulation on a machine prepared for maintenance to decrypt a user's password ( actually there are other means than the one described above to switch to the vt showing the decrypted password without being able to become root) but the chances of occurences of such a situation appear to me very, very low, so, feel free to remove this tag.

Cheers.

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.