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.

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.

See this thread I raised on the xorg mailing list
http://lists.freedesktop.org/archives/xorg/2009-May/thread.html#45750

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)

Created attachment 27173 [details]
LD_PRELOAD wrapper workaround

The workaround is inadequate as it breaks application functionality and makes them unusable

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

(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?

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.

What ever happened to this patch, did it make it in?

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

You may also want
http://cgit.freedesktop.org/xorg/xserver/commit/dix/grabs.c?id=5201310559fe8708ba8278bdef77cdc1673fff71

Why does it lead to security vulnerability now?

The X server option was supposedly secure when enabled *and* allowed deactivating grabs.

(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.

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.

(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.

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?

(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.

So that text in the man page for AllowDeactivateGrabs is bogus?

That text implies that a screenlocker could get around that.

(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.

Of course, the feature was removed and so was the description from the man page.

(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).

Could we have a DisableGrabs settings, which would disable keyboard grabbing globally (except for trusted applications such as screen savers)

Indeed, occasionally a buggy application will grab the keyboard out of the blue, and create serious disruption until the culprit is found. Even having to enter a magic "hotkey" to rid oneself of a grab maybe too cumbersome in some work flows, best would be to not let the grab happen in the first place.

Latest culprit: Firefox, with its "should I store the password" dialog box.
https://bugzilla.mozilla.org/show_bug.cgi?id=1386699