GNOME Bugzilla – Bug 776128
[wayland] a buggy or rogue client can force mutter to clear its own event mask
Last modified: 2016-12-15 12:19:16 UTC
Created attachment 342011 [details] Simple reproducer in C Description: A window manager must select the SubstructureRedirect mask on the root window to receive the MapRequest from the X11 clients and manage the clients. Using the X selection mechanism, It is possible for an buggy or rogue X11 client to force mutter to clear its own event mask, effectively turning mutter/gnome-shell into a regular X11 client not able to map any new X11 client window. How reproduible: Always Steps to reproduce: 1. Log onGNOME Wayland session 2. Check the root event mask: $ xwininfo -root -events Someone wants these events: StructureNotify SubstructureNotify SubstructureRedirect PropertyChange ColormapChange Do not propagate these events: Override redirection?: No 3. Run gtk3-demo and select some text $ gtk3-demo --run=textview 4. Save, compile and run the attached reproducer: $ gcc -o xselect -g xselect.c -lX11 5. Check the root event mask again now: $ xwininfo -root -events xwininfo: Window id: 0x270 (the root window) (has no name) Someone wants these events: Do not propagate these events: Override redirection?: No 6. For the fun, try to run xterm, or any other X11 client. Expected results: The event mask remains the same, new X11 client can map their windows. Actual result: The event mask on the root window has lost the SubstructureRedirect mask and X11 clients cannot map new windows anymore. Additional data: Fix coming...
Created attachment 342012 [details] [review] [PATCH] wayland: Preserve the event mask on the root window A window manager must select the SubstructureRedirect mask on the root window to receive the MapRequest from the X11 clients and manage the windows. Without this event mask set, a window manager won't be able to map any new window. The Wayland selection code in mutter can change/clear the event mask on the requestor window from a XSelectionRequest event when the window is not managed by mutter/gnome-shell. A rogue or simply buggy X11 client may send a XConvertSelection() on the root window and mutter will happily change/clear its own event mask on the root window, effectively turning itself into a regular X11 client unable to map any new X11 window from the other X11 clients. To avoid this, simply check that the requestor window is not the root window prior to change/clear the event mask on that window.
Comment on attachment 342012 [details] [review] [PATCH] wayland: Preserve the event mask on the root window It looks right. Nice catch :)
Review of attachment 342012 [details] [review]: This makes sense to me. We already listen for the needed events, so we don't need to poke at the root window event mask if a client is funny enough to use it. I'll leave it for Carlos to stamp any seal of approval though, since he knows X11 clipboard things far more than me.
Review of attachment 342012 [details] [review]: *restores the stamp of approval*
Just so it is clear, I think this is quite unexpected, and interacting with the clipboard through a window the client didn't create has dubious semantics (gets worse though if the root window were used as the selection owner). Still, I see nothing in ICCCM explicitly forbidding it, so there's high chances that there's software like that in the wild :), IMO the patch looks right.
(In reply to Carlos Garnacho from comment #5) > Just so it is clear, I think this is quite unexpected, and interacting with > the clipboard through a window the client didn't create has dubious > semantics (gets worse though if the root window were used as the selection > owner). Still, I see nothing in ICCCM explicitly forbidding it, so there's > high chances that there's software like that in the wild :), IMO the patch > looks right. FWIW, I hit this earlier today by some client (I don't know which one) other than the reproducer, and we after debugging we concluded that it must have been mutter that removed the mask itself (assuming it's not a bug in the X server), and this seems to be the only possible path that could result in something like that. So, it seems *something* on my system that I ran did this, or we have some other bug causing the same issue.
Unlikely another issue, trying to remove the SubstructureRedirect from the root window by another X11 client will result in an Xerror and the mask will remain. A bug in Xwayland itself is also unlikely, the resulting event mask looked very valid (not some random value) except of course that it was missing the SubstructureRedirect mask. So the only X11 client able to clear the SubstructureRedirect mask is mutter itself, and from there, the only code I could spot where mutter would call XSelectInput() on an event passed window is wayland_selection_data_new() and wayland_selection_data_free(). So I am quite confident this is the bug you ran into earlier.
Comment on attachment 342012 [details] [review] [PATCH] wayland: Preserve the event mask on the root window attachment 342012 [details] [review] pushed to git master as commit 7601250 - wayland: Preserve the event mask on the root window attachment 342012 [details] [review] pushed to branch gnome-3-22 as commit 06f5b6b - wayland: Preserve the event mask on the root window