Hello, fellow gnome-shell developers, in the past few weeks I saw that we started laying the plans for gradually moving gnome-shell to wayland, and it's my understanding, based on some wiki pages, that we want to run it straight on KMS/DRM + evdev. I would like to call out for the potential security implications of doing this, in particular on the evdev side: having an open handle to an event char device, however obtained, allows to see all input events in the system, including those from other sessions and virtual terminals. Currently weston handles this by simply refusing to pull events when on a different virtual terminal, but this solution is not acceptable for gnome-shell: we allow running arbitrary code from a variety of places, such as DBus and extensions, so it would be easy for a logged in attacker to keep logging events after the vt switch. On the KMS/DRM side, the risk is not calling drmDropMaster after the switch, thus keeping privileges that are enough to acquire the full content of the screen from a different session. Again, weston solves this assuming that the right message is sent to weston-launch, thus relying on an unprivileged and untrusted process.
The simple solution to both these problems is to have a system compositor running as root, which takes care to send events and accept buffers from the appropriate session only. My idea is that this system daemon would implement a small subset of the wayland API, enough to deliver events, monitor configuration and to accept fullscreen buffers ready for scanout. There would be another advantage of using a system compositor, and that brings us to the second part of my email: the relationship between GDK and Clutter in the mutter process. I can't find it right now, but I understood that, given gdk has no KMS+evdev backend, it will keep using the X11 backend with xwayland. This is of course hackish, with multiple steps that reinterpret events. Having a system compositor that talks wayland on the other hand would allow to make gdk the bottommost abstraction layer. Clutter would use the gdk backend, and mutter would learn to get events from gdk, by creating foreign windows in the X11 case, and client-side windows when running as a wayland server. Alternatively, we can remove the gdk/gtk+ dependency completely. For the record, mutter uses gtk+ for the following features: - event retrieval -> need to split the X11 parts (propertynotify, selectionnotify, configurerequest, etc.) from actual events, and then we can pull the latter from Clutter - tab/workspace popups -> not needed in gnome-shell, I'm ok if we say users of libmutter have to reimplement them - resize popups -> should be easy to reimplement in clutter - clipboard (in gnome-shell) -> would not work anyway, needs a wayland clipboard implementation in mutter - input methods (in gnome-shell) -> would not work anyway - window decorations and menus -> this is the hard part, as a clutter/st reimplementation will probably regress them, and it's a lot of code anyway - xsettings and icon theme (in gnome-shell) -> again, this is hard to do without Personally, I'm not yet convinced on which way can be the best, but I hope this can be the start of a productive discussion. Giovanni _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
