FS#27993 - [xorg] Bypassing screensaver/locker program on xorg 1.11 and up
Attached to Project:
Arch Linux
Opened by Vertlo Oraerk (oraerk) - Thursday, 19 January 2012, 10:15 GMT
Last edited by Eric Belanger (Snowman) - Monday, 23 January 2012, 20:15 GMT
Opened by Vertlo Oraerk (oraerk) - Thursday, 19 January 2012, 10:15 GMT
Last edited by Eric Belanger (Snowman) - Monday, 23 January 2012, 20:15 GMT
|
Details
Description:
Easily disable xlock with physical access to PC. All details: http://gu1.aeroxteam.fr/2012/01/19/bypass-screensaver-locker-program-xorg-111-and-up/ Additional info: * package version(s): X.Org > 1.11 * config and/or log files etc. Steps to reproduce: 1) Lock X.Org Session 2) Press Ctrl+Alt+Numpad Multiply 3) Session unlocked. That is it, easily. |
This task depends upon
Closed by Eric Belanger (Snowman)
Monday, 23 January 2012, 20:15 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in xkeyboard-config 2.4.1-3
Monday, 23 January 2012, 20:15 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in xkeyboard-config 2.4.1-3
Essentially, the bug remains, but it's not in [xorg], but rather [xscreensaver] and other screen-locking programs, as it's up to an individual program to disable the behavior (and screen-locking apps are exactly what should be doing that).
I will say, however, that sending the XF86ClearGrab will cause a screen locking program to quit. I am now uncertain whether it is possible for a program to disable that behavior, as there is some discussion on arch-general stating that a linked article is incorrect.
My case is simply that CTRL+ALT+KPMU sends XF85ClearGrab, and will kill xscreensaver (or alock) if it's doing its screen locking job. I made a custom keyboard layout with xkbcomp (and judicious application of vi), which is attached hereto. As pointed out on arch-general, this may indeed simply be a case of a keybinding that just shouldn't be there unless you are debugging full screen programs and are OK with the consequences.
If there was a way to retract my reopen request, I would have before you acted on it.
44,49c44,49
< interpret XF86_Ungrab {
< action = Private(type=0x86, data="Ungrab");
< };
< interpret XF86_ClearGrab {
< action = Private(type=0x86, data="ClsGrb");
< };
---
> // interpret XF86_Ungrab {
> // action = Private(type=0x86, data="Ungrab");
> // };
> // interpret XF86_ClearGrab {
> // action = Private(type=0x86, data="ClsGrb");
> // };
Really, it is a security hole while it is not fixed in a *lock programs, but a such simple workaround is good enough for the moment, IMHO...