xhost + required to launch app from Plasma menu since last Tumbleweed update


I had a heavy Tumbleweed update (300+) and since then, I cannot launch applications from the menu anymore:

  • if I press the menu shortcut key and type the first letters to narrow down to any app, then press Enter, I briefly see the bouncing icon as before, but the application is not launched
  • if I navigate in the menu with the mouse, same outcome
  • if I use the KRunner (Alt-F2), I can launch applications from there

After some research and tests, I found out that “xhost +” was a (bad) work-around. From the moment I disable access control to the screen, the menu works again.

Does it mean that now, applications are launched differently, with an impact on the access control?
Any idea if something is wrong, and how to solve the problem cleanly (other than adding “xhost +” to any startup script)?


– Redglyph

Operating System: openSUSE Tumbleweed 20200917
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.1
Kernel Version: 5.8.7-1-default
OS Type: 64-bit

The specific app you’re trying to run may have something to do with your problem.

Years ago,
xhost + was recognized to be a serious security problem and attempts were made to patch it then and several times since but the warning has always been the same… this method to launch apps is risky and will always be subject to modifications over time as it continues to be patched when vulnerabilities are found.


It’s any app, the problem is the same for all of them, be that system or user, installed initially or later.
All of them fail to launch, and all of them launch after an “xhost +”.

I know the “xhost +” is risky, that’s why I wrote it’s a bad work-around and would like to fix the problem more cleanly :wink:

I cannot reproduce it on TW 20200917. Are you using X11 or Wayland session?

You have probably misconfigured something.

Open a terminal (konsole), and check the output from


Here, it give


If you just get a blank line as output, then you have somehow managed to undefine $XAUTHORITY and that would cause the problem you are seeing.

Previously, Plasma and SDDM were using $HOME/.Xauthority for authenticating windows. But a recent update changed that.

The general rule, since forever, has been: Use $XAUTHORITY if that is define; otherwise use $HOME/.Xauthority

Now SDDM sets up $XAUTHORITY on login, and puts the authentication cookie there. If you undefine it, you will have problems.


XAUTHORITY is defined.

I haven’t changed my configuration and it was fine before, but perhaps something went missing or relied on something that disappeared.
After the update, for instance, “man” was not there anymore, I had to uninstall / reinstall it. Perhaps I should look for the update log to see any suspicious message.

Then the question should be asked (sorry, but unavoidable): How did you do that 'update".

Run any program that does not start in terminal and post full command line and any output/error message.

After the update, for instance, “man” was not there anymore

This is well known problem. TW 20200917 (that you are using according to your original post) contains fix for this issue so it is entirely unrelated to the issue you are describing here.

Meh. Now it’s working again…

Not sure what happened, I had rebooted after the update and the problem appeared then.
One reboot later, and it’s gone. Perhaps there were post-kernel-update pending actions that left the configuration in a bad state?

Next time I’ll probably reboot twice.

Anyway, thanks for all your answers! :slight_smile:

(just to answer that)

sudo zypper dup

Thanks again!

Thats is fine then.

Nice all is working again.