Feature changed by: Stefan Behlert (sbehlert) Feature #322297, revision 34 Title: Yast2 working in wayland openSUSE Distribution: Implementation Priority Requester: Important Requested by: Andreas Winter (netzheimer) Requested by: Frederic Crozat (fcrozat) Requested by: Kai Dupke (kdupke) + Requested by: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: 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 solutions: - 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. https://bugzilla.opensuse.org/show_bug.cgi?id=955101 Discussion: #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: xhost +SI:localuser:root 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 or X. 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 #16) 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 display). 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. -- openSUSE Feature: https://features.opensuse.org/322297