Bug 21652 - AllowDeactivateGrabs no longer works
AllowDeactivateGrabs no longer works
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Server/General
unspecified
All All
: medium normal
Assigned To: Daniel Stone
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-10 00:16 UTC by Justin Clift
Modified: 2012-04-02 07:48 UTC (History)
7 users (show)

See Also:


Attachments
LD_PRELOAD wrapper workaround (828 bytes, application/octet-stream)
2009-06-26 09:28 UTC, Serge van den Boom
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Clift 2009-05-10 00:16:57 UTC
Just upgraded to a new version of X (xorg 1.6), and found that AllowDeactivateGrabs has been removed from it's capabilities:

  http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b47104a26c0524385

Went looking for equivalent functionality, but it doesn't seem to be present.

If that's the case, this is a critical regression/bug for applications that require it in order to work.  ie. Salasaga (www.salasaga.org)

Regards and best wishes,

Justin Clift
Comment 1 David Campbell 2009-05-25 03:34:07 UTC
This is a show-stopper for GUI application development because if any of the code breakpoints inside a menu selection that grabs X, and you're running stand alone, then you're completely and indefinitely locked out of your desktop, and your only option is to suffer data loss by rebooting.

Comment 2 David Campbell 2009-05-25 16:08:59 UTC
This needs to be urgently fixed.  I simply cannot work as a GUI software developer with this X server without the ability to escape grabs and get back to the debugger after a breakpoint in menu code that causes a grab lock.

The absence of AllowDeactivateGrabs is unworkable.

I've had to roll back to an old X server version that includes this functionality to be able to do my development work.

Comment 3 David Campbell 2009-05-25 21:04:59 UTC
See this thread I raised on the xorg mailing list
http://lists.freedesktop.org/archives/xorg/2009-May/thread.html#45750
Comment 4 Serge van den Boom 2009-06-26 09:27:33 UTC
Here's a workaround (see attachment): an LD_PRELOAD wrapper which intercepts the input grabbing functions and makes them do nothing at all. It's bound to have some small side effects (such as menus not disappearing when you click outside of the application), but at least it makes it possible to use breakpoints in places where the keyboard/mouse would otherwise be grabbed.

To compile:
    gcc -shared -o xgrab.so xgrab.c

And then run your IDE as:
    LD_PRELOAD=/path/to/xgrab.so eclipse
(or something similar)
Comment 5 Serge van den Boom 2009-06-26 09:28:31 UTC
Created attachment 27173 [details]
LD_PRELOAD wrapper workaround
Comment 6 David Campbell 2010-12-30 12:21:53 UTC
The workaround is inadequate as it breaks application functionality and makes them unusable
Comment 8 Artem Anisimov 2011-03-26 08:01:38 UTC
(In reply to comment #7)
> these may help:
> http://cgit.freedesktop.org/~daniels/xserver/commit/?h=input-next&id=0e40f3d286970aaf81f3c84d337eb035e1d064d7
> and:
> http://cgit.freedesktop.org/~daniels/xserver/commit/?h=input-next&id=ff4efa75fba16c099295b0cc6a5b9e44386b8427

Could you please explain how the new actions are supposed to be used? Are they available in X distribution from freedesktop, or I have to patch the server?
Comment 9 Daniel Stone 2011-06-14 17:03:02 UTC
Yep, you'll have to patch the server.  I've proposed them for 1.11 here:
http://lists.x.org/archives/xorg-devel/2011-June/023313.html

You can apply those two patches (or get them from git://people.freedesktop.org/~daniels/xserver in the master branch); instructions on how to use the new actions are available in the commit message for the second patch.
Comment 10 Adam Nielsen 2012-03-31 18:54:50 UTC
What ever happened to this patch, did it make it in?
Comment 11 Alan Coopersmith 2012-03-31 18:56:21 UTC
Yes, it's in 1.11, leading to a security vulnerability if you didn't upgrade
xkeyboard-config to 2.5 as well:
http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html
Comment 13 Michal Suchanek 2012-04-02 03:33:41 UTC
Why does it lead to security vulnerability now?

The X server option was supposedly secure when enabled *and* allowed deactivating grabs.
Comment 14 Daniel Stone 2012-04-02 03:46:09 UTC
(In reply to comment #13)
> Why does it lead to security vulnerability now?
> 
> The X server option was supposedly secure when enabled *and* allowed
> deactivating grabs.

Because, due to a catastrophic miscommunication, it was enabled by default in xkeyboard-config.  Meaning that anyone could walk up to anyone's machine and kill the screensaver.
Comment 15 Michal Suchanek 2012-04-02 03:54:33 UTC
The old in-server option had the below text meaning that it was supposed to be secure *when enabled*.

Why was this not preserved in the XKB ?

Option "AllowClosedownGrabs" "boolean"
    This option enables the use of the Ctrl+Alt+Keypad-Multiply key sequence to kill clients with an active keyboard or mouse grab as well as killing any application that may have locked the server, normally using the XGrabServer(3) Xlib function. Default: off.
    Note that the options AllowDeactivateGrabs and AllowClosedownGrabs will allow users to remove the grab used by screen saver/locker programs. An API was written to such cases. If you enable this option, make sure your screen saver/locker is updated.
Comment 16 Daniel Stone 2012-04-02 04:07:49 UTC
(In reply to comment #15)
> The old in-server option had the below text meaning that it was supposed to be
> secure *when enabled*.
> 
> Why was this not preserved in the XKB ?

We felt that configuring it through XKB offered a much easier and discoverable alternative than making people generate an xorg.conf file solely to add one option, and having to restart their server whenever they wanted to change it.

As the option (rather sensibly) defaulted to false, making the XKB approach respect that as well would've made it near on useless.

But yes, in hindsight, this shouldn't have been removed in the first place.  C'est la vie.
Comment 17 Michal Suchanek 2012-04-02 04:14:23 UTC
And to state this clearly, the XKB option does no longer support the screen locker API so you can either have grab debugging or secure X server but not both anymore, or am I misunderstanding something?
Comment 18 Daniel Stone 2012-04-02 04:16:56 UTC
(In reply to comment #17)
> And to state this clearly, the XKB option does no longer support the screen
> locker API so you can either have grab debugging or secure X server but not
> both anymore, or am I misunderstanding something?

Screensavers secure the screen by grabbing all input devices so they can capture all input, rather than have people be able to interact with other windows, alt-tab away from the screensaver, etc.

The grab breaking option, breaks all grabs.  And one of its modes is to kill all clients with currently active grabs.  Which, if you're debugging a broken app or toolkit, will kill your app.  Or, if a screensaver is active, will kill the screensaver.

This is nothing new: it's true of the new XKB-based action configuration, but it was equally as true of the previous keybindings prior to 1.6.  Which is exactly why it was disabled by default.
Comment 19 Michal Suchanek 2012-04-02 04:24:31 UTC
So that text in the man page for AllowDeactivateGrabs is bogus?

That text implies that a screenlocker could get around that.
Comment 20 Daniel Stone 2012-04-02 04:27:32 UTC
(In reply to comment #19)
> So that text in the man page for AllowDeactivateGrabs is bogus?
> 
> That text implies that a screenlocker could get around that.

Indeed.  Though, to be fair, the text isn't in the manpage anymore.
Comment 21 Michal Suchanek 2012-04-02 05:13:01 UTC
Of course, the feature was removed and so was the description from the man page.
Comment 22 Alan Coopersmith 2012-04-02 07:48:21 UTC
(In reply to comment #19)
> So that text in the man page for AllowDeactivateGrabs is bogus?
> 
> That text implies that a screenlocker could get around that.

Previously screensavers could make an XFree86Misc extension API call
to disable the grab killing functionality, which is why the old feature
was considered a security issue when XFree86Misc was removed from the
X server.

Today a screensaver could make calls equivalent to setxkbmap to remove
the grab:break_actions option when locking and restore it on unlock,
but I am not aware of any that do so (nor have we reached out to any
to point out they could).