Subject: Re: wsmux inject
To: Steven M. Bellovin <>
From: Garrett D'Amore <>
List: tech-kern
Date: 03/14/2006 16:01:08
Steven M. Bellovin wrote:
> On Tue, 14 Mar 2006 23:17:12 +0000 (GMT), Iain Hibbert
> <> wrote:
>> On Wed, 15 Mar 2006, Valeriy E. Ushakov wrote:
>>> With current code you can inject events into the mux for processes
>>> that read from the mux (as your hexdump exepriment demonstrates),
>>> e.g. you should be able to inject events for x server to read from the
>>> mux, but you cannot inject "terminal input" for /dev/ttyE*
>> Hm, I see..  (vaguely :)
>>> To feed terminal input from user space, you need a way to inject raw
>>> scancodes that need to end up being passed to wskbd_input.
>> Well, it seems that I could do that quite simply by creating a
>> WSKBDIO_INJECT ioctl in wskbd_displayioctl() though thats a bit of a
>> bodge..
>> I'm thinking it would likely be better to make a pseudo-device that would
>> attach as a wsbkdN when necessary, not sure if that will work as planned.
> Have the ability to inject keyboard and mouse events, though useful for
> many purposes, poses serious security issues that should be thought
> through.  The issue is ancient; see
> or
> about TIOCSTI, for example,
> or the discussion about allowSendEvents in the xterm man page.
> >From that perspective, requiring a separate driver is a good thing,
> since it's then easy to exclude from the system.
> 		--Steven M. Bellovin,

FYI, this is in the context of Bluetooth.  I believe that we need to
have something.  It isn't necessarily true that having a mechanism that
is accessible from userland is a good idea, but at least from the kernel
(or a trusted root process) we need the ability.

    -- Garrett

Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191