Plasma Wayland relocatability

[Martin Gräßlin]

Am 2017-02-21 12:48, schrieb Harald Sitter:
> # startplasmacompositor
> 
> - Resolves qdbus via qtpaths which is not relocatable, that's not
> really our fault and probably not too easy to solve or even worth it.
> Finding qdbus reliably has been a long standing problem unfortunately.
>  - Hard-compiles the kwin_wayland path. I think this is actually
> security relevant and necessary. startplasmacompsitor would already
> have a user environment, so it could have a bad PATH with a
> kwin_wayland ontop of the actual kwin_wayland. I'd actually find it
> better if this script got replaced by kwin_wayland or a C/C++ helper.
> If /bin/sh is a symlink to /bin/bash the environment easily can be
> full of rubbish from the user session which may or may not be seeking
> to exploit kwin.

Nah that doesn't belong into KWin - it would create a dependency loop.

Personally I would prefer a systemd-user session approach or something 
in that way to get away from the shell scripts.

> - Hard-compiles the startplasma path
> 
> # xwayland
> 
> Xwayland is simply not relocatable as xkbcomp's full path is 
> hard-compiled.

That should then also apply to kwin itself. At least if we want to get 
the layout flags into the sni we will have to hard compile in the 
evdev.xml path which I think is what is the case with xkbcomp's full 
path?

> 
> # startplasma
> 
> - Actually executes qdbus from PATH where startplasmacompositor took
> great care to grab it from qpaths, that seems silly. I am thinking
> either both should run from PATH or none.
> - Hard-compiles start_kdeinit_wrapper
> - Hard-compiles ksmserver
> 
> # kinit
>> $ ls -lah /usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
>> -rwxr-xr-x 1 root root 11K Feb 14 18:22 
>> /usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
> 
> Well, that's a lie. Probably incorrectly ported somewhere along the 
> line.

Of just no longer needed. If we worked three years without anyone 
noticing breakage we can go for the Xorg deprecation model. (For those 
not knowing: break by accident, remove once you notice it's broken 
without a single bug report several years later)

> 
> But I hear you asking what the point of start_kdeinit is. Comment 
> again:
> 
>> Prevent getting killed by bad heuristic in Linux OOM-killer.
>> This wrapper decreases the chance OOM killer kills it (or its 
>> children,
>> namely kdeinit)
> 
> Yeah, that's not really working now is it.
> 
>> $ cat /proc/`pidof kdeinit5`/oom_*
>> 0
>> 1
>> 0
> 
> More importantly this makes no sense. See reference table from above,
> everything depends on kwin_wayland, kwin_wayland doesn't OOM adj, so
> whether or not kdeinit is OOM adjusted is fairly irrelevant as kwin
> might get murdered causing everything to get murdered. (Xorg isn't
> decreased either, so same there).
> 
> But let's take step back here. start_kdeinit wants to OOM adjust so
> that it doesn't get murdered. How old is this code?

Fair guess: 1996

> In kernel 2.6.39 already the score is documented as a value of
> badness. Over simplified: the more memory a process uses, the worse
> its score, the more likely is it to get killed during OOM handling.
> So, how in the world would kdeinit5 have such a bad score that it gets 
> murderd?
> This entire construct makes no sense to me and should be dropped, the
> way I see it this is overengineered nonsense.

or 1996, but same result ;-)

> 
> # kdeinit5
> 
> - Hard-compiles path to klauncher
> - Should be dropped in favor of dbus activation or systemd socket
> activation (slightly out of scope, I know ;))
> 
> # ksmserver
> 
> Starting here things seem to largely not be hardcoded anymore. Rejoice!
> 
> # conclusion
> 
> - startkdeinit is making me angry
> - We have a real problem with libexec. 90% of hardcompiled paths I
> tend to find are frameworks things that need to run something from
> libexec. Hardcompiling seems like a massive hack for finding where
> your libexec is. I am not sure how to best resolve this, but I'd
> imagine QStandardPaths could do with an extension to handle paths
> within library paths.

The porting guide for everything libexec from KStandardDirs was hard 
compile.

We have a few valid cases with libexec, e.g. kscreenlocker_greet to 
kcheckpass, or kwin to kscreenlocker_greet, but that's it.

Nice investigation!

Cheers
Martin