Bug 372197

How does the XAUTHORITY look like for e.g. kwin_x11?

Side note: this seems to also affect the "Logout", "Reboot" Actions from KDE->Leave menu

for pid in 2388 2389 2393 2446 2428 2433 2439 ; do echo -n "$pid: " ; cat /proc/$pid/cmdline | tr '\0' ' ' ; echo -ne "\n\t" ; cat /proc/$pid/environ | tr '\0' '\n' | grep XAUTHORITY; echo ; done

2388: /usr/lib64/libexec/kf5/start_kdeinit --kded +kcminit_startup 
        XAUTHORITY=/home/sbruens/.Xauthority

2389: kdeinit5: Running...                                   

2393: kded5 [kdeinit5]                                       

2446: /usr/bin/konsole -session 101bc139153117000146712520700000035260022_1478617649_467193 
        XAUTHORITY=/tmp/xauth-1000-_0

2428: /usr/bin/ksmserver 
        XAUTHORITY=/home/sbruens/.Xauthority

2433: kwin_x11 -session 101bc139153117000142961805600000019630002_1478617650_383503 
        XAUTHORITY=/home/sbruens/.Xauthority

2439: plasmashell --shut-up 
        XAUTHORITY=/home/sbruens/.Xauthority



pstree -A -p sbruens | grep  '+'
akonadi_control(2602)-+-akonadi_akonote(2940)-+-{QDBusConnection}(2944)
                      |-akonadi_archive(2941)-+-{QDBusConnection}(2951)
                      ...
                      |-akonadi_notes_a(3072)-+-{QDBusConnection}(3097)
                      |-akonadi_sendlat(3078)-+-{QDBusConnection}(3116)
                      |-akonadiserver(2612)-+-mysqld(2636)-+-{mysqld}(2664)
at-spi-bus-laun(2867)-+-{dconf worker}(2869)
dconf-service(2425)-+-{gdbus}(2430)
gnome-keyring-d(2688)-+-{gdbus}(2698)
gvfsd(2884)-+-{gdbus}(2886)
gvfsd-fuse(2889)-+-{gdbus}(2903)
kaccess(2401)-+-{QDBusConnection}(2402)
kactivitymanage(2481)-+-{QDBusConnection}(2483)
kdeinit5(2389)-+-firefox(2512)-+-Web Content(3000)-+-{Chrome_ChildThr}(3008)
               |-kded5(2393)-+-{QDBusConnection}(2398)
               |-klauncher(2390)-+-{QDBusConnection}(2392)
               |-konsole(2446)-+-bash(2661)
               |               |-bash(2741)-+-grep(4753)
               |-korgac(2464)-+-{QDBusConnection}(2517)
               |-ksmserver(2428)-+-baloo_file(2436)---{QDBusConnection}(2452)
               |                 |-krunner(2437)-+-{QDBusConnection}(2458)
               |                 |-kwin_x11(2433)-+-{QDBusConnection}(2434)
               |                 |-plasmashell(2439)-+-{QDBusConnection}(2453)
               |                 |-polkit-kde-auth(2440)-+-{QDBusConnection}(2445)
               |                 |-xembedsniproxy(2441)-+-{QDBusConnection}(2451)
               `-org_kde_powerde(2456)-+-{QDBusConnection}(2461)
kglobalaccel5(2412)-+-{QDBusConnection}(2415)
kscreen_backend(2417)-+-{QDBusConnection}(2427)
kwalletd5(2610)-+-{QDBusConnection}(2633)
pulseaudio(2503)-+-{alsa-sink-ALC66}(2564)
startkde(2266)-+-gpg-agent(2352)

Given the output it seems like konsole is the odd one. It's a dbus activated application as far as I know.

Anyway I think you need to forward this report to your distribution. Somehow the wrong xauthority ends up in your session. That is outside of kde's code

All processes with ~/.Xauthority are children of ksmserver, so this is expected.

powerdevil, akonadi, firefox all have /tmp/xauth_1000-_0 in its env.

In the end all processes should be children of ksmserver. It's weird if you have processes which are not.

But anyway: distro topic

The processes which are not children of ksmserver are all programs which were restored from a previous session.

Actually, both ~/.Xauthority and /tmp/xauth-$UID-_$DISPLAY are correct locations, see https://cgit.kde.org/kinit.git/tree/src/kdeinit/kinit.cpp#n1470 for details.

The problem is caused by sddm.

When selecting "Switch User" and then starting a new session for an already logged in user (which I triggered inadvertently from the lock screen, which sometimes misbehaves on a dual screen setup - different bug), sddm replaces the contents of the ~/Xauthority file.

Good investigation! But that also means it's not a bug in our software. We can hardly protect against another process replacing the authority file ;-)

Although I agree its not a bug in kscreenlocker, I still have two remarks:

1. kscreenlocker_greet is hard to debug, as it immediate turns of ptrac'ing, and only allows it late during the initialization if '--testing' is set. Imho it would be better to only disable ptrace right before app.exec().

I think from a security standpoint this would be fine as well, but allowed catching errors during initilization.

Relevant greeter code:
https://github.com/KDE/kscreenlocker/blob/42ad07d79785e51641f97f7d20709fee6ab54060/greeter/main.cpp#L63

If you agree, I would prepare a patch.


2. stderr is not catched by the screen locker daemon. When starting kscreenlocker_greet manually, e.g.:
$> XAUTHORITY=/home/stefan/.Xauthority_  /usr/lib64/libexec/kscreenlocker_greet --testing
No protocol specified
QXcbConnection: Could not connect to display :0
Abgebrochen

, there is a somewhat helpful error message ("No protocol specified" points clearly to xauth problems).

No, I disagree on the ptrace change. It's important to get it set before any interaction with the windowing system is done. And that happens in QGuiApplication. Thus it needs to be before that.

The problem is also not the disable of ptrace, but the multi process architecture in general. In the source tree there is another test top which can simulate the architecture without having to rely on ksmserver. But requires to build from source.