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
>        `-

Attachment: signature.asc
Description: PGP signature

Reply via email to