Nathaniel Smith <[EMAIL PROTECTED]> wrote: > I didn't make the connection to the POLA gui problem either, but now > that you mention it it's an obvious point! All interaction with the > user's real X server is performed by a small and simple client > application (~400 lines of python) that doesn't know how to initiate > a grab, create a passive grab, steal focus, or other such antisocial > behaviors.
Right. That means that when you say, in the docs, "it doesn't support window icons, transient hints, shaped windows, cursor changing, input grabs, clipboard sharing, etc.", that is actually a feature from a security point of view. > The main issues I can think of would be: > -- Clients can still pop up arbitrary override-redirect windows, > including ones that completely cover the desktop. > Override-redirect windows never get keyboard focus, but they can > steal mouse events (and keyboard modifier state, since X mouse > events include that). They can't paint an image of the real > desktop on the override-redirect window, though (because they > don't have enough access to take a screenshot), which reduces the > effects of this. Is it the compositing extension that tells xpra when OverrideRedirect windows are opened? It should be possible to limit these OverrideRedirect windows. The first part is to choose a policy. I can imagine some policies for dealing with tooltip windows and menu windows, such as: Tooltips: - May not be under the pointer. Moving the pointer onto the tooltip closes it. - The pointer must be over a window of the client opening the tooltip. Moving the pointer away from the client's window closes the tooltip. - Clicking closes tooltips. - However, a client does not need the focus to open a tooltip. Menus: - Must be contiguous with the parent window. - The parent window must be focused. Losing the focus closes any child menus. - Pressing Escape closes menus. (taken from my notes at http://plash.beasts.org/wiki/X11TopLevelWindows) However, we can't tell the difference between menus and tooltips to apply different rules. X toolkits could be modified to add hints to these windows, but until then we need generic rules to apply to all OverrideRedirect windows. One generic rule would be not to allow OverrideRedirect windows to appear outside the parent window at all. They would be clipped. (We would need some heuristic to decide what the parent window is.) We could relax this rule and allow OverrideRedirect windows to appear outside the parent while the parent has the focus, but only below the title bar, so that the window manager's widgets are not obscured. Maybe the OverrideRedirect windows should be required to be contiguous with the parent (no gap allowed). > -- Multiple clients running through the same xpra also share a > single Xvfb, and thus can interfere with each other. > Theoretically this isn't much of an issue -- you probably want > separate proxy processes *anyway* for serving multiple clients, > to reduce the chance of bugs -- but the need to manage multiple > such processes makes UI trickier, and wastes resources. (E.g., > each Xvfb allocates a full frame-buffer, which is not actually > used.) Probably not the main worries at this stage in the game. Would I be right in thinking that Xvfb will never write anything into its framebuffer? If so, at worst it wastes swap space, if Xvfb initialises the buffer with that strange hatching pattern that X11 has as a default background that makes displays go funny sometimes. If we can persuade Xvfb to not even initialise it, perhaps the pages would never get faulted in. What happens if we give Xvfb a display size a lot smaller than the real display? Does it mess some X clients up? > -- Generally, maintaining synchronization between the state > displayed by the xpra client to the user and the state actually > existing on the Xvfb is very tricky. For instance, if xpra is > wrong about which Xvfb client has focus, then keystrokes directed > into one proxy window might go to another underlying window. > That per se is not really a problem (it's really just an instance > of the previous problem), but there is lots of state in X and > the same problem could arise in many different guises. Of > course, xpra tries hard to be robust against such issues, but > there is always the potential for bugs, and in general when > writing security software, an architecture that allows > desynchronization of real state and displayed state is one that I > would want to examine very carefully. Yes, this is the main thing that concerns me. I looked at modifying Xnest to be rootless a while back. I discovered that Xnest ignores the input event processing that the host X server does to determine the destination window, and re-runs the event through its standard X event processing logic (which I found really difficult to follow at the time), which means the window trees have to be kept in sync. The same applies to expose events, I think. Rootless mode for X (as used by Cygwin's X server) has to do the same trick. If it works there, I suppose there is a reasonably good chance it can work for xpra, though I don't know how much use X/Cygwin gets. Xnext and X/Cygwin have to keep the window trees in sync in order to make the display appear correctly. Does xpra avoid that by using the compositing extension? Would I be right in thinking that Xvfb maintains a backing store for all the top-level windows? When I looked at Xnest, it seemed to be dealing with grabs that made the input event processing code complicated. I have since discovered that X's complex grab features are mostly not used or needed, at least by normal clients that aren't window managers. You can just ignore GrabKeyboard, GrabPointer, GrabKey and GrabButton and things still work (I've tried this with an X proxy [1]). It stops Gtk menus from working when dragged: ironically, the workaround is to do UngrabPointer when you get GrabPointer [2]. UngrabPointer releases the implicit grab that is in effect while the mouse button is held down, which makes X report events the way Gtk expects. It might be practical to feed input events in to Xvfb at a different level if the current approach turns out not to be robust, even if it means ignoring grabs. Regards, Mark [1] http://plash.beasts.org/wiki/X11ProxySpike [2] http://svn.gna.org/viewcvs/plash?rev=732&view=rev _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
