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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-gnome+ow...@opensuse.org
