[adding x...@lists.x.org to CC, dropping t...@security.debian.org; please retain all CCs]
Dear Xorg developers, > […] I recently became a co-maintainer for the xtrlock screen locking utility. As part of this, I noticed a bug report filed by Antoine Amarilli which points out that so-called multitouch events are not blocked when xtrlock is enabled: https://bugs.debian.org/830726 This means that some applications (notably Chromium) can still be controlled even when the machine is locked down. When I looked at the code and the documentation regarding multitouch events, this was "to be expected" due to it only calling the XGrabPointer function. I therefore extended the code to enumerate over all multitouch devices and lock them too via XIGrabDevice as part of the version 2 of the X Input Extensions: https://bugs.debian.org/830726#43 However, Antoine then pointed out that this would not prevent an attacker plugging in such a multitouch device *after* xtrlock has been started and thus permit controlling the desktop. I thus revised the patch to detect the introduction of the new device via the XI_HierarchyChanged event: https://bugs.debian.org/830726#65 This appeared to work initially but we were seeing some strange behaviour where the touchscreen is not "correctly" grabbed; one can still work around the grab using multiple fingers (eg. press somewhere, then interact with Chromium) but some even weirder behaviour whereby grabs will persist *after* the xtrlock process has ended! For more detail about this, please see: https://bugs.debian.org/830726#90 I would be interested in your input here. Hopefully I am doing something obviously bogus which you will be able to point out for a quick and easy fix but I have a gut feel something deeper is awry given that locks persist beyond the end of the process. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
