Feature changed by: Stefan Behlert (sbehlert)
Feature #322297, revision 34
Title: Yast2 working in wayland
openSUSE Distribution: Implementation
Requested by: Andreas Winter (netzheimer)
Requested by: Frederic Crozat (fcrozat)
Requested by: Kai Dupke (kdupke)
+ Requested by: Stefan Behlert (sbehlert)
Partner organization: openSUSE.org
Wayland is coming with big steps. First distributions (eg fedora)
already use it as default. Gnome should be already stable with it,
Plasmas support is getting better and better. Some other DE already
support it out of the box. Wayland is a lot more secure than Xserver
and it is the future. I think it is time to bring Yast2's support for
this. At the moment a user who wants to run wayland has just 2
- Running yast in textmode (which is not a solution for non-geek users)
- Switch to another distribution, which offers better support
There were already some bugs opened by opensuse users. So you see the
feature is already needed.
#1: Dominique Leuenberger (dimstar_suse) (2017-02-18 01:04:12)
Just repeating here the workaround from the bug (so you have a VERY
good workaround between your two options provided): xhost +LOCAL:
This entire issue is not limited to YaST - but in fact ANY GUI
application running as a different user (most likely root)
#2: Frederic Crozat (fcrozat) (2017-02-20 16:50:39Z) (reply to #1)
However, there is an interesting question here: why isn't YaST able to
start in Wayland mode directly, since it is using Qt5. It should be
able to run natively in Wayland and not requires X11..
#3: Frederic Crozat (fcrozat) (2017-02-21 13:55:20Z) (reply to #1)
A "slightly" more secure way:
This is equivalent to the current security model used currently on
SLE12 / Leap.
#4: Frederic Crozat (fcrozat) (2017-02-21 14:11:37Z)
yast2 control center (Qt) or yast2 modules can be started in Wayland
after installing libqt5-wayland and setting "QT_QPA_PLATFORM=wayland".
But you need to be a regular user
#12: Scott Reeves (sreeves1) (2017-11-08 01:13:16Z) (reply to #7)
Starting in Beta2 a desktop file is installed in /etc/xdg/autostart
that adds +SI:localuser:root to the server access control list for the
user. Other options like xinitrc.d, gnome-session or gdm do not work as
they are not run in wayland, wrong timing and don't stick, need to be
added to the users xserver. This options also allows this to work for
other desktops like KDE and can be easily modified by the admin by
changing this desktop file.
#15: Frederic Crozat (fcrozat) (2018-01-11 16:54:04Z) (reply to #12)
similar fix has landed in Tumbleweed. Closing as done on openSUSE
#16: Ludwig Nussel (lnussel) (2018-01-22 12:37:04Z) (reply to #15)
Unfortuantely the "fix" did not land in Factory so far.
The currently implemented solution is not an acceptable one in my
opinion. This autostart file that was added unconditionally and always
grants root access to the display. Independent of whether there is a
need and independent of whether the system is actually running wayland
In X we already have pam_xauth that is exactly for this purpose. It
grants the target user access to the display on demand and revokes it
afterwards. What about extending that mechanism instead?
#17: Hans Petter Jansson (hpjansson) (2018-01-22 23:25:35) (reply to
It's a hack while we wait for applications to be fixed. We chose to do it
this way because it's fairly minimal (no need to invent configuration
keys or rebase patches down the road) and user serviceable (the
autostart file can be removed to make it harder for root to access your
When we tested xauth we found there was no auth data to forward AFAIR.
What does a pam_xauth-based solution look like?
#13: Daniel Ziltener (zilti) (2017-12-25 12:07:42) (reply to #4)
Where do I have to set this variable to get it to work?
#14: Frederic Crozat (fcrozat) (2018-01-11 16:53:34Z) (reply to #13)
in your user environment.
#10: Keith Hizal (kah0922) (2017-09-20 17:09:30)
In the end xhost +SI:localuser:root is just a workaround and not a long
term solution. With Wayland not budging on running GUI apps as root, it
probably will be necessary run yast as a normal user and ask for the
root password once changes are made (possibly using polkit).
#11: Sławomir Lach (lachu) (2017-10-09 18:28:27) (reply to #10)
I think due to security reasons, you can select one of solution below:
1) Create list of trusted Wayland compositors and allow to run
application as another user only on it 2) Allow to start single program
in new Wayland session, but without desktop (only compositor and
programs are running). When user tries to start second and next
programs as this user, programs will start in the same Wayland sessions
3) (I don't know if it is possible, because I don't know low level
kernel internals, but). Create Wayland proxy, which would be run as
root, so can run tasks as another user. When user decides to run
program as another user, virtual window will be created. When this
window isn't window nearest to user, user can interact with desktop
normally. In other case overlay of windows belonged to user this window
is connected will be displayed. When user click outside own window,
overlay will minimize.
Please tell me if you cannot understand my ideas. I must wrote, I
didn't know Wayland internals, UDev and Linux kernel internals well.