Ich setze in diesem Artikel voraus, dass ein Anwender, der ab und zu grafische Qt-Anwendungen wie etwa yast2 als User “root” startet, KDE-spezifische Font- und andere Darstellungs-Einstellungen für eben jenen User “root” mittels des Kommandos “systemsettings5” vorgenommen hat. Diese Einstellungen sollen bereits unter einem KDE5-Plasma-Desktop, der vom User Root gestartet wurde, getestet worden sein.
Unter Opensuse 13.1/13.2 wurden solche Darstellungsvorgaben auch umgesetzt, wenn Qt4-Anwendungen von einem Terminalfenster des KDE4-Desktops eines unpriviligierten (!) Users aus
- entweder über “kdesu”
- oder auch als User Root nach einem Login mittels “su -”
startete. Gilt das auch für Qt5-Anwendungen des KDE5-Plasma-Desktops von Opensuse Leap 42.1?
Das Problem
Nein, es gilt nicht in jedem Fall. Eine entsprechende Unzulänglichkeit des KDE 5-Plasma-Desktops und seiner Qt5-Anwendungen zeigt sich in folgendem Verhalten:
- Man hat als normaler unpriviligierter User eine KDE5-Plasma-Sitzung gestartet.
- Alternative 1: Man öffne z.B. ein “konsole”-Fenster im root-Modus (=Systemverwaltungs-Modus) oder logge sich in einem beliebigen Terminalfenster-Anwendung als root mit “su – ” ein. Man starte dann eine Anwendung (wie etwa “yast2”, dolphin, kate, …), die bereits auf Basis von Qt5 läuft.
- Alternative 2: Man öffne eine anderes Terminalfenster und starte die gleiche Anwendung (z.B. yast2) mal mit “kdesu” – also z.B. “kdesu yast2”.
Im Fall der Alternative 1 zum Start der Qt5-Anwendung werden lediglich ein Standard-Font (mit sehr kleiner font-size von 10px) und Standard-Icon-Einstellungen gezogen. Als Folge tut man sich z.B. auf hochauflösenden Bildschirmen mit dem Lesen schwer; zudem werden bestimmte Icons (mangels Existenz) gar nicht dargestellt.
Dagegen werden bei Alternative 2 die für den Root-User getroffenen und gewünschten KDE5 Font- und Symbol-Einstellungen verwendet.
Ursachen
Ein wenig Forschung zeigt, dass das beschriebene negative Resultat für Alternative 1 von zwei Faktoren abhängt:
- dem Anlegen root-spezifischer Environment-Variablen durch “su -” für eine im Terminalfenster gestartete Root-Login-Shell,
- der Tatsache, dass Qt5 erwartet, dass die Umgebungsvariable
“XDG_CURRENT_DESKTOP=KDE”
gesetzt ist, was nach einer durch “su -” geöffneten Login-Shell aber nicht der Fall ist.
Vergleichbares passiert(e) unter OS13.1/13.2 und auch unter Leap 42.1 für KDE4- oder auch GTK-Anwendungen nicht.
Übrigens: Startet man einen Plasma5-Desktop als User “root” (und nicht wie oben vorausgesetzt als unpriviligierter User), so setzt der “kdeinit5”-Prozess die richtigen Umgebungsvariablen für alle weiteren Prozesse. Das Problem fiele dem User Root in dieser Situation also nur dann auf, wenn er in einem Terminal nochmals eine Login-Shell starten würde; was in diesem Fall aber überflüssig wäre und was man deshalb typischerweise auch nicht tun würde.
Eigentlich kann man niemandem eine Schuld am festgestellten Verhalten geben. Weder SuSE, noch KDE, noch den Qt-Entwicklern. Dennoch ist der Punkt in der täglichen Praxis etwas ärgerlich.
Lösungsansatz
Was kann man nun tun, wenn einen die sehr kleinen Standardfonts der aus einer root-Konsole gestarteten Qt5-Anwendungen im KDE-Desktop eines Standard-Users stören? Der einfachste, aber nicht ganz unproblematische Lösungsansatz besteht darin, die genannte Umgebungsvariable für eine root-Login-Shell standardmäßig über eine Anweisung in der Datei “/root/.profile” zu setzen. Wer weiß aber, welche
Folgen das hat, wenn man gelegentlich auch mal unter Gnome oder XFCE arbeitet?
Mein Weg zur Lösung des Problems war deshalb, mir mal das Ergebnis von
ps axo pid,ppid,sess,uid,cmd
genauer anzusehen – nachdem der Root-Login erfolgt ist.
Verfolgt man die Prozesskette vom Start der Qt5-Anwendung durch root, so wird man unweigerlich über die Elternprozesse auf das Öffnen des Terminalfensters (z.B. konsole) durch den unpriviligierten User stoßen. Im “Sess”-Feld des letzteren Prozesses ist dann u.a. ein eindeutiger Bezug zum Prozess “kdeinit5: Running…” gegeben, der wiederum vom unpriviligierten User gestartet wurde. Das ist dann ein klarer Hinweis darauf, dass eine KDE5-Desktop-Umgebung vorliegt.
Diese Auswertung der Elternprozesse kann man nach dem Starten einer Root-Login-Shell natürlich auch über adäquate Befehle zur Auswertung des “ps”-Outputs in der “/root/.profile” vornehmen lassen. Stellt man auf diesem Wege fest, dass die aktuelle Root-Shell in einem Terminalfenster unter der KDE5-Desktop-Umgebung eines unpriviligierten Users gestartet wird, so setzt man die benötigte Umgebungsvariable dann einfach per
export XDG_CURRENT_DESKTOP=KDE
Ich hoffe dieser Tipp hilft dem einen oder anderen, der als Root nicht ausschließlich auf der Kommandozeile arbeitet.
Nachtrag 01.11.2016: Sicherere Lösung: kdesu …
Aus der Perspektive der Sicherheit gilt natürlich, dass root am besten keine grafischen Applikationen in einer fremden KDE-Umgebung startet. Ein Weg, der das obere Problem vermeidet und mehr Sicherheit schafft, ist in den aktuellen KDE5-Versionen selbstverständlich der, dass man die benötigte Applikation vom Terminalfenster eines unpriviligierten Users aus mit “kdesu” startet. Im Fall von “systemsettings5” also
kdesu systemsettings5 &
Offenbar sorgt “kdesu” für die benötigte Umgebungsvariable. Was man mit “kdesu konsole &” und einem “env | grep XDG” im anschließend geöffneten Terminalfenster leicht überprüfen kann.
Nachtrag 01.11.2016: SSH führt zum gleichen Problem – auch für normale User
Ich sollte an dieser Stelle anfügen, dass das Aufrufen einer SSH-Sitzung auch für normale User zum gleichen Problem führt, wie wir es hier für den User “root” diskutiert haben. Siehe hierzu:
SSH – Qt5-Anwendungen – KDE/Plasma 5 – falsche Fonts und fehlende Icons
