linux-kernel - Re: Re (hello?): [PATCH] Let keyboard notifiers modify key codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090113014545.GG5026@const.famille.thibault.fr>
Date:	Tue, 13 Jan 2009 02:45:45 +0100
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Derek Fawcus <dfawcus@...co.com>
Cc:	linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
	linux-input@...r.kernel.org
Subject: Re: Re (hello?): [PATCH] Let keyboard notifiers modify key codes

Derek Fawcus, le Tue 13 Jan 2009 01:06:13 +0000, a écrit :
> > Yes, that seems a bit unsafe to me.  Another solution is to just grab
> > all the keyboard devices, and reemit the wanted evdev keycodes.  Quite
> > clumsy.
> 
> reemit?  as in inject back to the kernel?

Through uinput, yes.

> How does one prevent loops?

By not grabbing the evdev corresponding to your own uinput dev.  IIRC it
can even work with several daemons doing so, the last being only able to
grab the last uinput's evdev.  If a daemon hangs, no luck, however.

> > > I'm not sure w/o reading the code if the kernel will allow this to be
> > > shared between the tty and evdev on the same vt,
> > 
> > What do you mean by "this"?
> 
> I was referring to being able to read the evdev data from the keyboard
> while still allowing the vt to consume the data.  Can one filter out
> just keys of interest,  or will reading the /dev/input/eventX prevent
> the keys being fed to the vt and hence to /dev/ttyXX?

Grabbing does prevent it yes.  But feeding through uinput puts it back
to the console.

> > > but then one could run a controller program talking through a pty and
> > > direct to the keyboard.
> > 
> > Ugh.  I'd prefer grabing evdev rather that using a pty.
> 
> Well using the pty is not too bad,  and some stuff seems unhappy unless
> fed from a tty of some form (default line buffering for stdin/stdout,
> job control with bash).

The problem with ptys too is that they manipulate letters, not physical
key position, thus loosing keyboard mapping independence.

> Anyway,  wouldn't this all be easier with a app running on X and
> XKEYBOARD/XKB manipulations?  Have the key that does left/right
> swapping simply be a group toggle action in the definition file.

Sure, but sometimes you're left without X, and that's not a reason for
suddenly completely loose typing speed.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/