2016-07-10 20:30:02 UTC
xtrlock appears not to block multitouch events when the session is locked, so
that any user stumbling upon a locked session can still input multitouch events.
One could imagine that this could constitute a security vulnerability (requiring
physical access to the machine).
Steps to reproduce (on a computer with a suitably configured touchscreen):
1. Open chromium (my example of a program that processes multitouch events) and
put it in fullscreen mode.
2. Check that you can pinch and zoom (put two fingers of the screen and move
them closer or further apart to change the zoom level).
3. Run xtrlock to lock the session.
4. With xtrlock running, put one finger on the screen and leave it there (the
mouse pointer with the xtrlock lock icon follows that finger). While doing this,
perform the pinch and zoom with two other fingers.
The pinch and zoom is taken into account by chromium even though the session is
The event should not be seen by chromium while the session is locked.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages xtrlock depends on:
ii libc6 2.22-13
ii libx11-6 2:1.6.3-1
xtrlock recommends no packages.
xtrlock suggests no packages.
-- debconf-show failed