Hi Chris, Thanks for writing the patch! I tested it on <https://salsa.debian.org/debian/xtrlock.git>. For some reason it didn't apply cleanly to debian/rules, but it did apply fine to xtrlock.c and I manually added -DMULTITOUCH to debian/rules to enable it.
So, the patch works fine on my machine. All input from the touchscreen seems to be blocked (in particular touching the touchscreen no longer moves the mouse cursor with the lock icon). However, I think I see a problem with the patch's design. If I understand correctly, the patch makes xtrlock grab all devices initially. But if the attacker plugs in a new device after xtrlock is started (e.g., an USB multitouch trackpad), then it wouldn't be grabbed, right? I can't try out this exact scenario because I don't have such a USB device, and I can't easily disconnect my laptop's touchscreen. However, I have tried blocking the touchscreen by writing 0 to /sys/bus/usb/devices/3-1.5/authorized (the touchscreen then disappears from the output of xinput). If I run "sleep 10 ; echo 1 | sudo tee authorized" in the background and run xtrlock (to simulate plugging in the touchscreen after 10 seconds), then sure enough, once the touchscreen is "plugged" it is not grabbed by xtrlock and the initial problem still occurs. Of course the patch is already a big improvement, but do you have any idea about how to address this problem with new devices being plugged in while xtrlock is running? Best, -- Antoine Amarilli On Fri, Aug 16, 2019 at 05:46:07PM -0700, Chris Lamb wrote: > Chris Lamb wrote: > > > Patch attached that works for me on my Dell XPS 13 > > Antoine, does the patch attached to: > > https://bugs.debian.org/830726#43 > > … also work for you? If so, I will go ahead and upload. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org 🍥 chris-lamb.co.uk > `-
signature.asc
Description: PGP signature