[Bug 211246] [syscons] console and ttyv0 competing for keystrokes

[Bruce Evans]

On Wed, 20 Jul 2016 bugzilla-noreply at freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211246
>
>            Bug ID: 211246
>           Summary: [syscons] console and ttyv0 competing for keystrokes
>           Product: Base System
>           Version: 10.3-RELEASE
>          Hardware: i386
>                OS: Any
>            Status: New
>          Severity: Affects Only Me
>          Priority: ---
>         Component: kern
>          Assignee: freebsd-bugs at FreeBSD.org
>          Reporter: alexander.klein at physiologie.med.uni-giessen.de
>                CC: freebsd-i386 at FreeBSD.org
>                CC: freebsd-i386 at FreeBSD.org

bugzilla inhibits replies not only to itself, but to the Reporter.

> On my system, ttyv0 and console are competing for keystrokes on the
> ttyv0-screen. This can be seen when logging in under X, immediately issuing
>
> % xconsole -file /dev/console
>
> in an xterm, switching to ttyv0 by pressing Ctrl+Alt+F1, and then typing some
> text.
>
> In most cases, the typed text will appear in the Xconsole-window, and even if
> this doesn't happen immediately, hammering the keys fast enough with a few
> <Ret>s interspersed will usually make at least some characters appear in the
> Xconsole-window.
>
> This might have security implications when parts of login credentials are
> redirected.
>
> As an aside, things written to /dev/console invariably appear on the
> ttyv0-screen on my system, but are never passed on to xconsole.

This seems to be the expected behaviour.  You asked for foot-shooting and
got it.  This is not a security hole since it requires root privilege.

xconsole without -f should use the correct file.  If not, try /dev/tty or
$(tty).

xconsole on /dev/console is like the better-known configuration error of
running getty on /dev/console and the physical device underlying
/dev/console -- since there is only 1 physical device, i/o must be
shared between the open files in some indeterminate way.  ioctls also
get shared.  Except before FreeBSD-8, syscons had magic resulting in
not sharing termios, and that mostly worked better.

xconsole under FreeBSD-11 with a FreeBSD-~5.2 userland and a FreeBSD-4
ports version of X fails due to permissions problems here, but I saw
exactly the same behaviour in the simpler setup of logins on ttyv0
and ttyv1 and a program on ttyv1 grabbing the console using

     int c = 1; ioctl(0, TIOCCONS, &c);".

xconsole with no args works correctly under FreeBSD-~5.2.

xconsole -f /dev/console doesn't fail as expected  under FreeBSD-~5.2.
In fact, it works the same as xconsole with no args:
     input on ttyv0 is not stolen and is echoed to ttyv0
     input on console not tested (xconsole window is output-only)
     echo to console goes to xconsole window
This might be due to the magic non-sharing in syscons before FreeBSD-8.
Someone should test the old versions on a serial console without this
magic.

The tty layer also got signficant plumbing changes for consoles starting
in FreeBSD, partly to reduce the need for hacks like syscons' magic.
Apparently the magic is needed somewhere.  The top layer could with
the current restriction to only a physical device for the top level
console, but that restriction is wrong, and the changes in FreeBSD
increased it.  In general, there should be multiple consoles with a
different physical device for each, and clearly the settings for things
like the line speed on a serial console cannot be shared.  Then for
each physical device, you might want to keep the settings for things
not like the line speed separate.  You might even want yet another set
of settings for the low level console.  The latter set is now hard-coded
in some device drivers and the initial state and lock state devices
are supposed to be configured to match this state.

Bruce