Bypass events and get the physical keyboard state directly

[Bryan Baldwin]

Yup, the encryption was an automagickal client mistake.

And I understand all your points, and don't disagree with the security model. I just don't think that the people and the software that are assuming responsibility for system security should be. I'm not afraid to go and look, then tear it up and write my own thing if its a good use of time. I think its going to be a very good use of time these days ;)

For posterity, the input problem I had is a bug in SDL2. Pressing and holding down a key was not producing events with the repeat flag set. It produced pairs of keydown & pressed - keyup & released events without the repeat flag set. These events continued to be send long after the key was physically released. It is an untenable expectation for the application to track key state with garbage input.

This is a known SDL2 bug affecting at least verisons 2.0.4
https://bugzilla.libsdl.org/show_bug.cgi?id=3472 and 2.0.5.

There is a patch I've tested locally on my own system, and it works.
https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2594


On 02/20/2017 11:17 PM, Pekka Paalanen wrote:
> (I think you just sent an encrypted email to a mailing list. I assume
> this was an accident, since nothing indicates otherwise.)
>
>
> On Mon, 20 Feb 2017 21:56:03 +1300
> Bryan Baldwin <bryan at katofiad.co.nz> wrote:
>
>> I don't know why you mentioned Wayland. As a reference point? I'm not
>> presently developing with a Wayland target.
> Yes, as a reference point.
>
>> I cannot track the state of the keyboard with the events I received,
>> because, as described, they are garbage. Something between evdev and
>> my code screws the input data. X11, GNOME, or SDL2. Out of that
>> stack, X11 would have been my goto to look for a way to view input
>> more directly, which is why I asked about your interfaces here, but
>> even that was completely wrong.
> There is probably a reason why something somewhere converts repeats
> into up/down pairs, if that is the only problem you have. You could try
> finding out which component is responsible for it, and ask on the
> appropriate mailing list why it is so and how to work around it.
>
> I would also hazard a guess that these up/down pairs come really close
> to each other, so if you actually drained the event queue before
> looking at the tracked keyboard state, maybe it would be what you need.
> But that is just speculation from me.
>
> FWIW, Wayland does not have repeat events itself. A toolkit may
> manufacture those any way it wants based on keyboard state (the exact
> state you seem to be wanting in the first place).
>
>> Initial code tests I've made directly against evdev prove that the
>> input seen is accurate and properly reported. Grabbing all the input
>> devices is easy. Releasing and reacquiring all of them based on
>> window focus is easy. Identifying what each device is and which to
>> use is easy. I have no idea what you are talking about with Re: to
>> permissions and security. I'm not sure where in the original software
>> stack the input code is being ruined, but to whomever code that
>> belongs, if you cannot deliver accurate input from the kernel with
>> 100% confidence, you cannot be trusted to decide permissions or
>> security, either.
> I'm not convinced, but I won't argue about the easyness.
>
> The security/permissions problem is this: if you are allowed to open
> the input devices, you can also trivially implement an invisible
> keylogger, just "forget" to close the devices. Obviously people don't
> like that idea, hence in a usual system the input device permissions
> are restricted, probably as far as to the root user. Hence your game
> needs to run as root, or ask the user to bypass the set permissions
> e.g. by adding himself to the 'input' group (which now opens the door
> for keyloggers). Display servers often use logind DBus API to open input
> devices to avoid running as root, but I believe logind would refuse
> your game if a display server was also active at the same time.
>
>
> Thanks,
> pq
>
>
>> On 02/20/2017 09:20 PM, Pekka Paalanen wrote:
>>> On Mon, 20 Feb 2017 12:37:36 +1300
>>> Bryan Baldwin <bryan at katofiad.co.nz> wrote:
>>>  
>>>> Okay, so further investigation has lead me to test code against
>>>> evdev directly. Nevermind ;)  
>>> But if you run under any kind of display server (windowing system),
>>> that won't usually work at all, or works wrong.
>>>
>>> That is also why any kind of "bypass the display server" will not
>>> generally work. There is a myriad of reasons for that, including
>>> permission and security issues, even starting from how to even pick
>>> the right devices.
>>>
>>> You really are expected to keep the keyboard state tracked in your
>>> app, based on the events. Even evdev works like that. If you were
>>> writing for Wayland, there would be libxkbcommon to do that, and I
>>> believe SDL2 already uses libxkbcommon anyway (on Wayland).
>>>
>>> OTOH, if you were not running under any display server, then you'd
>>> be fine with that approach.
>>>
>>> Your question would be better directed at SDL or the specific window
>>> system fora (e.g. mailing lists).
>>>
>>>
>>> Thanks,
>>> pq  
>>


-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170221/cad221c4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature_sml.png
Type: image/png
Size: 10748 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170221/cad221c4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD64E442F.asc
Type: application/pgp-keys
Size: 3074 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170221/cad221c4/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170221/cad221c4/attachment-0001.sig>