[opensuse-gnome] Running Xorg non-root
Hi Guys, The Gnome team and the team dealing with the hardware pieces of the graphics stack should have a conversation about running X 'non-root'. On openSUSE Tumbleweed gdm is the first DM to run the Xserver without root permissions. An Xserver run as non-root will attempt to acquire permissions for devices from system-logind. Output: ======= Currently, on Tumbleweed, when using 'gdm' as login manager, Xwayland will be started on top of a Wayland Display Server if possible. If the Wayland display server cannot be started, ie. when no suitable driver is around - for instance, when the boot option 'nomodeset' is used, gdm will attempt to start Xorg as user 'gdm'. Once the login succeeds, gdm will start a regular Xserver as the logged in user. At SUSE we still support UMS drivers - including fbdev. In fact, fbdev is part of the fallback strategy we employ: since fbdev uses a VESA mode (which today is set by grub2), this mode will always be available. The UMS driver will fail immediately once the Xserver attempts to load them without root permissions. For the 'fbdev' it depends: this driver only requires access to /dev/fb<N> which allows group access of the 'video' group. Thus the user 'gdm' is able to start it, any other user will fail. This can be fixed by either setting the appropirate file ACLs or using systemd-logind granted access. Setting ACLs for devices is done for DRI devices in /dev/dri/ - it used to be handled by ConsoleKit but is done by uaccess for systemd, today. The bigger challange will be UMS devices. For these the only option I see would be to start them as root or to use a wrapper script to do this (this seems to be the present solution at Debian). The question which remains is, how does GDM know that a wrapper script is required? It would be easy to test for the presence of KMS, however, this will often include cases where fbdev can be used. I'm open to suggestions here ;) - after all, this decision needs to be made in GDM. Input: ====== All evdev input devices are handled by systemd-logind. It remains to check if drivers requiring /dev/input/mouse* or /dev/input/mice need to be equipped with an interface for obtaining the necessary permissions as well. There is one exception among the input drivers: xf86-input-vmmouse. This driver used for guest VMs on VMWare and KVM uses a rather obscure interface - an emulated PIO register. I'm not sure if this device is still supported by KVM, VMWare doesn't strictly require it, however if used, it used to enhance VMWare's capabilities. We may have to drop this driver as I would like to avoid having to use a wrapper for this. So, looking into handling access to /dev/fb<N> and some of the older input devices would be my task. You Gnome folks should consider how to decide when to use a wrapper. For the wrapper code, we should probably cooperate with Debian. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
ti., 12.01.2016 kl. 13.56 +0100, skrev Egbert Eich:
The bigger challange will be UMS devices. For these the only option I see would be to start them as root or to use a wrapper script to do this (this seems to be the present solution at Debian). The question which remains is, how does GDM know that a wrapper script is required? It would be easy to test for the presence of KMS, however, this will often include cases where fbdev can be used. I'm open to suggestions here ;) - after all, this decision needs to be made in GDM.
For openSUSE I'd be fine with this not being automatic, as in we provide a suid-wrapper-"compat" package, but do not install it by default. Those who need it have to install it, and since that will lead to only users in need, always apply it when installed. This will hopefully "encourage" upstreams to port their drivers, or switch to other ones.
From what I understood from a virtualbox bug I was cc'ed on, Oracle is already underway with theirs.
Input: ======
For input drivers upstream have already dropped all mouse support for non-libinput drivers (at least for configuration, I've not verified if one can still use synaptic/foo but not configure them via gnome-tools) https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=66c211ff2 4bec6a938d6a6a0dd8730f4689ef383 https://bugzilla.gnome.org/show_bug.cgi?id=759595 This will kinda force us to Require xf86-input-libinput for the next release, so I guess that more or less "taken care off" /Bjørn -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
Egbert, On Tue, 2016-01-12 at 13:56 +0100, Egbert Eich wrote:
Hi Guys,
The Gnome team and the team dealing with the hardware pieces of the graphics stack should have a conversation about running X 'non-root'.
On openSUSE Tumbleweed gdm is the first DM to run the Xserver without root permissions. An Xserver run as non-root will attempt to acquire permissions for devices from system-logind.
Thanks for bringing this forward here.
Output: ======= Currently, on Tumbleweed, when using 'gdm' as login manager, Xwayland will be started on top of a Wayland Display Server if possible. If the Wayland display server cannot be started, ie. when no suitable driver is around - for instance, when the boot option 'nomodeset' is used, gdm will attempt to start Xorg as user 'gdm'. Once the login succeeds, gdm will start a regular Xserver as the logged in user.
That is true up to version 3.18 of GNOME unless the user explicitly selects to run the user session on Wayland too (wich is possible) with GNOME 3.20, the 'default' is actually being switched to also have the user session as a wayland based session with XWayland on top of that. GNOME on X.org will remain an option (to be selected in the login session chooser) - We are not yet fully decided if we're not switching this back to be GNOME on X as default though (there are some unresolved issues like starting of any root GUI app not being possible so far, e.g YaST - which is a blocker)
At SUSE we still support UMS drivers - including fbdev. In fact, fbdev is part of the fallback strategy we employ: since fbdev uses a VESA mode (which today is set by grub2), this mode will always be available.
The UMS driver will fail immediately once the Xserver attempts to load them without root permissions. For the 'fbdev' it depends: this driver only requires access to /dev/fb<N> which allows group access of the 'video' group. Thus the user 'gdm' is able to start it, any other user will fail. This can be fixed by either setting the appropirate file ACLs or using systemd-logind granted access. Setting ACLs for devices is done for DRI devices in /dev/dri/ - it used to be handled by ConsoleKit but is done by uaccess for systemd, today.
The bigger challange will be UMS devices. For these the only option I see would be to start them as root or to use a wrapper script to do this (this seems to be the present solution at Debian).\ The question which remains is, how does GDM know that a wrapper script is required? It would be easy to test for the presence of KMS, however, this will often include cases where fbdev can be used. I'm open to suggestions here ;) - after all, this decision needs to be made in GDM.
This sounds all very much like the suid wrapper Hans de Goede submitted into the X source tree almost a year ago: - X is being started as user if it can and as root if it cannot. - As it's a wrapper, and not just integrated into X, it can be split of into a separate package (as is done by Debian and Fedora) - Legacy drivers can require the suid wrapper (as is done in above mentioned distributions) Any special treating of GDM is wrong imho: it's just the first DF that knows how to handle Wayland - and it won't stay the only. gdm doesn't have to know that the wrapper is required: it uses the wrapper when it's on the system - the wrapper decides if it wants to spawn X as root or if it's safe to drop the privileges and run X as user (the first case is basically the same we have in all other DMs: X is run as root - with full root privileges; no dropping of privileges happens) Dominique -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
participants (3)
-
Bjørn Lie -
Dominique Leuenberger / DimStar -
Egbert Eich