debianforum.de

Verfasst: **21.08.2019 15:08:48**

Seit dem Upgrade von Stretch auf Buster können einige KDE-GUI-Programme aus Sicherheitsgründen (die mir nicht ganz einleuchten) nicht mehr als root gestartet werden, egal ob aus der Konsole, per kdesu, per sudo oder per pkexec. Das betrifft z.B. Dolphin, Kate und Kwrite. Als Administrator möchte ich weiterhin komfortabel arbeiten können, daher brauche ich diese Programme, die ich auch als normaler Benutzer verwende. Wie kann ich das hinbekommen?

Verfasst: **21.08.2019 15:16:56**

Zur Zeit wohl gar nicht. Du wirst eine Root-X-Session

starten müssen.

Grüße Günther

Verfasst: **21.08.2019 15:47:35**

Ulidor hat geschrieben:
21.08.2019 15:08:48
Wie kann ich das hinbekommen?

Genauso, wie man es seit 25 Jahren machen muß:

Code: Alles auswählen

su -
export XAUTHORITY=/home/DeinUsername/.Xauthority
DeinSuperUserProgramm

Verfasst: **21.08.2019 16:16:47**

Leider werden Fake- Nachrichten immer öfter

bei mir geht das (Standard - Installation, nicht verändert) mit

Code: Alles auswählen

synaptic-pkexec

gparted:

Code: Alles auswählen

/usr/sbin/gparted %f

in beiden Fällen kommt dies Fenster:

Wenn da noch was anderes im Starter steht (wg. Upgrade) sollte das zu ändern sein.

Das hatte ich übrigens in einem Beitrag gerade vor ein paar Tagen auch schon geschrieben. Tja und in Buster ist es genauso:
viewtopic.php?f=2&t=174408&start=15#p1214781

Verfasst: **21.08.2019 16:25:29**

MSfree hat geschrieben:
21.08.2019 15:47:35
Genauso, wie man es seit 25 Jahren machen muß:
Code: Alles auswählen
su -
export XAUTHORITY=/home/DeinUsername/.Xauthority
DeinSuperUserProgramm

Auch das klappt bei mir nicht:

Code: Alles auswählen

$ su -
Passwort: 
# export XAUTHORITY=/home/rolf/.Xauthority
# kate
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

Kate habe ich jetzt doch mit pkexec zum Laufen bekommen:

Code: Alles auswählen

$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY kate
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

Mit Dolphin klappt das heute seltsamerweise auch mit pkexec. Ich bin mir ziemlich sicher, gestern nach dem Upgrade das alles ausprobiert zu haben, da bekam ich immer nur Fehlermeldungen.

@ guennid:
Ich hatte auch schon überlegt, eine Root-X-Session anzulegen, wie es ja bei alten Debian-Versionen mal eingerichtet war. Aber ich hoffe, mit pkexec komme ich erst mal klar.

Vielen Dank euch beiden!

Verfasst: **21.08.2019 16:32:59**

@ willy4711:

Mir ging es eigentlich darum, wie ich generell mit GUI-Programmen als root arbeiten kann. Synaptic und Gparted verwende ich nicht (das mache ich wiederum lieber in der Konsole). Aber danke für den Hinweis.

Verfasst: **21.08.2019 16:44:03**

Kate geht doch:

Code: Alles auswählen

root@willy-pc:/home/willy# kate /etc/apt/sources.list
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
root@willy-pc:/home/willy#

Problemlos was reingekritzelt

Code: Alles auswählen

cat /etc/apt/sources.list
# das ist ein Test
# das ist noch ein test
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free

deb http://deb.debian.org/debian buster-updates main contrib non-free
deb-src http://deb.debian.org/debian buster-updates main contrib non-free

# deb http://security.debian.org/debian-security/ buster/updates main
# deb-src http://security.debian.org/debian-security/ buster/updates main
deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free

Verfasst: **21.08.2019 16:53:42**

Ulidor hat geschrieben:
21.08.2019 16:32:59
Mir ging es eigentlich darum, wie ich generell mit GUI-Programmen als root arbeiten kann. Synaptic und Gparted verwende ich nicht (das mache ich wiederum lieber in der Konsole). Aber danke für den Hinweis.

Schreib den Befehl in einen Starter, dann braucht du noch nicht einmal die Konsole, um Dolphin als Root zu starten, und kannst aus dem Root- Dolphin
problemlos Dateien mit Root Rechten bearbeiten
Achso hab den Befehl ja noch nicht publiziert

Code: Alles auswählen

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin

Verfasst: **21.08.2019 17:02:33**

willy4711 hat geschrieben:

21.08.2019 16:44:03

Kate geht doch:

Code: Alles auswählen

root@willy-pc:/home/willy# kate /etc/apt/sources.list
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
root@willy-pc:/home/willy#

Hm, bei mir geht es nicht:

Code: Alles auswählen

rolf@ulidor:~ $ su -
Passwort: 
ulidor:~ # kate /etc/apt/sources.list
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

Und in einer mit kdesu geöffneten root-Konsole:

Code: Alles auswählen

ulidor:~ # kate /etc/apt/sources.list
Executing Kate with kdesu is not possible due to unfixable security vulnerabilities.

In was für einer Konsole arbeitest du, dass es bei dir geht?

Verfasst: **21.08.2019 17:07:32**

willy4711 hat geschrieben:
21.08.2019 16:53:42
Achso hab den Befehl ja noch nicht publiziert
Code: Alles auswählen
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin

Ich habe meine Starter-Befehle abgeändert, damit geht es. Aber ich habe die Optionen "KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true" nicht drin. Braucht man die? Bei mir geht es auch ohne.

Verfasst: **21.08.2019 17:09:08**

Schau mal genau hin:

Code: Alles auswählen

willy@willy-pc:~$ su -
Passwort: 
root@willy-pc:~# 
root@willy-pc:~# kate /etc/apt/sources.list
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.
root@willy-pc:~# Abgemeldet
willy@willy-pc:~$ su
Passwort: 
root@willy-pc:/home/willy# kate /etc/apt/sources.list
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
root@willy-pc:/home/willy#

Ulidor hat geschrieben:
21.08.2019 17:07:32
Ich habe meine Starter-Befehle abgeändert, damit geht es. Aber ich habe die Optionen "KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true" nicht drin. Braucht man die? Bei mir geht es auch ohne.

Dann ist es ja gut. Hab die Dinger mir auch nur irgendwann aus dem Netz gefischt

Verfasst: **21.08.2019 17:11:12**

die mir nicht ganz einleuchten

Dann solltest du die Finger von lassen. X11 ist halt unsicher by Design. Und die Workarouns sind grauenhaft und gehen dauernd kaputt und defakto versucht es glaube ich heute keiner mehr das hin zu bekommen X11 ist zu verkorkst das sauber hin zu bekommen und es wird auch nicht gebraucht.
Es gibt deutlich sinnvollere Methoden sowas zu Erledigen. Üblicherweise Dateien weg kopieren editieren zurück kopieren, wie das z.B. sudoedit macht, dass du auch mit Kate verwenden kannst. (sudoedit -e kate /etc/bla) Dazu brauchst du aber halt ein eingerichtetes sudo. Emacs kann den tramp mode. Ich hätte schwören können, dass KIO das auch irgend wie kann. Finde es jetzt aber nicht.

Ich habe meine Starter-Befehle abgeändert, damit geht es. Aber ich habe die Optionen "KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true" nicht drin. Braucht man die? Bei mir geht es auch ohne.

Habt ihr irgend eine Ahnung was ihr damit anrichtet?

Verfasst: **21.08.2019 17:14:03**

wanne hat geschrieben:
21.08.2019 17:11:12
Habt ihr irgend eine Ahnung was ihr damit anrichtet?

Na erkläre doch mal

Verfasst: **21.08.2019 17:16:02**

willy4711 hat geschrieben:
21.08.2019 17:09:08
Dann ist es ja gut. Hab die Dinger mir auch nur irgendwann aus dem Netz gefischt

Hab die Optionen jetzt ausprobiert: Dolphin ist damit besser ins System integriert.

So bin ich bestens zufrieden, vielen Dank!

Verfasst: **21.08.2019 17:21:46**

wanne hat geschrieben:
21.08.2019 17:11:12
Habt ihr irgend eine Ahnung was ihr damit anrichtet?

Ich möchte nur das machen, was ich schon seit vielen Debian-Generationen mache: Als root komfortabel arbeiten.

Was mir bei dem neuen Sicherheitskonzept nicht einleichtet: Wenn ich als root arbeite, dann bin ich mir der Gefahren bewusst. Also was kann dann schon passieren? Warum jetzt diese Einschränkungen? Ich fühle mich bevormundet, und das von einem eigentlich freien System.

Verfasst: **21.08.2019 17:22:55**

@ wanne
Anrichten tut es laut Terminal folgendes:

Code: Alles auswählen

~$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Trying to convert empty KLocalizedString to QString.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 1490, result = 0
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: opened connection to :0
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/trash.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/trash.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/thumbnail.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Qt: Session management error: networkIdsList argument is NULL
kdeinit5: PID 1497 terminated.
kdeinit5: PID 1495 terminated.
kdeinit5: PID 1494 terminated.
kdeinit5: PID 1498 terminated.

Aber ehrlich, ich benutze KDE Aus diesem Grund so gut wie gar nicht mehr. Wenn die Entwickler aus irgend einem nicht nachvollziehbaren
Sicherheitstaumel ein DE dermaßen zerschießen, bevor sie eine Lösung gefunden haben, sucht halt die Community nach einer Lösung,
damit das System wieder Nutzbar ist.Und diese ist halt eine. Die andere wäre:

Code: Alles auswählen

apt purge kde* plasma*

Verfasst: **21.08.2019 17:34:07**

wanne hat geschrieben:
21.08.2019 17:11:12
Dann solltest du die Finger von lassen. X11 ist halt unsicher by Design. Und die Workarouns sind grauenhaft und gehen dauernd kaputt und defakto versucht es glaube ich heute keiner mehr das hin zu bekommen X11 ist zu verkorkst das sauber hin zu bekommen und es wird auch nicht gebraucht.

Nun, das ist ja wohl einen KDE- Spezialität. Unter Xfce arbeite ich ausschließlich mit dem Policykit, und rufe Die mir wichtigen Programm
über die entsprechenden Policies ausschließlich mit

Code: Alles auswählen

pkexec <Programm >

auf. Was bitte ist daran falsch? Wenn es falsch und unsicher wäre, warum wird es dann in Debian angeboten und teilweise per Installer
so vorgegeben.

Und nein - um einen Datei zu editieren hacke ich nicht zuerst auf der Konsole rum

Verfasst: **21.08.2019 19:20:28**

willy4711 hat geschrieben:Das hatte ich übrigens in einem Beitrag gerade vor ein paar Tagen auch schon geschrieben.

Den fand ich wirr und habe die Wirrnis diametral entgegengesetzt interpretiert.
Hier stellt es sich jetzt so dar: Kein Login-Manager, keine DE, kein systemd und ergo kein policykit-1, ergo kein pkexec auf der buster-Maschine. Als Root geht unter einem Benutzter-X (openbox) nichts mehr, kein grafischer Editor (leafpad), kein gparted. Damit dürfte Buster die erste Debian-Version sein, auf der man ohne systemd nicht mehr sinnvoll arbeiten kann - richtig?

MSfree hat geschrieben:
Code: Alles auswählen
su -
export XAUTHORITY=/home/DeinUsername/.Xauthority
DeinSuperUserProgramm

Ich musste das die letzten fünfzehn Jahre noch nie machen und geholfen hat's auch nicht. Falls Terminal-Meldungen gewünscht werden - mach' ich gerne, aber dann muss ich mir diese (Test-)Maschine an den Schreibtisch holen. Per ssh erscheint mir das nicht sinnvoll.
Grüße, Günther

Verfasst: **22.08.2019 22:23:18**

guennid hat geschrieben:
21.08.2019 19:20:28
MSfree hat geschrieben:
Code: Alles auswählen
su -
export XAUTHORITY=/home/DeinUsername/.Xauthority
DeinSuperUserProgramm
Ich musste das die letzten fünfzehn Jahre noch nie machen und geholfen hat's auch nicht.

OK, ich habe da eine Kleinigkeit übersehen:

Code: Alles auswählen

su -
Passwort: 
root@j1900:/home/user# export  XAUTHORITY=~user/.Xauthority 
root@j1900:/home/user# export DISPLAY=:0
root@j1900:/home/user# kate
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0

und schon habe ich den K-Editor auf dem Bildschirm.

Wie gesagt, das ist schon echt eine Ewigkeit so, zum ersten Mal bin ich darüber unter Irix 5.1 "gestolpert", einem Unix, das ich 1992 auf einer Indigo2 von Slicon Graphics laufen hatte. Wenn man als fremder Benutzer (hier root) auf das Display des Users malen will, braucht man die Berechtigung für das Display, was über die Datei .Xauthority passiert und man muß dem Programm mitteilen, auf welches Display er malen soll, hier das lokale Display, das immer ":0" heißt.

Verfasst: **23.08.2019 13:31:20**

Ulidor hat geschrieben:
21.08.2019 17:21:46
Ich möchte nur das machen, was ich schon seit vielen Debian-Generationen mache: Als root komfortabel arbeiten.
Was mir bei dem neuen Sicherheitskonzept nicht einleichtet: Wenn ich als root arbeite, dann bin ich mir der Gefahren bewusst. Also was kann dann schon passieren? Warum jetzt diese Einschränkungen? Ich fühle mich bevormundet, und das von einem eigentlich freien System.

Genau so ist es!
Seit Jahren mache ich es ebenso: als Root komfortabel arbeiten, und zwar so, wie ich es will!
@wanne
Laß' doch diese Äußerungen. Das hieße im Umkehrschluß doch, daß ich grafisch als Root das System zerschieße, aber wenn ich auf der Konsole als Root arbeite, kann das nicht passieren?
Kleiner Scherz, oder? Als Root habe ich immer meinen Kopf einzuschalten, egal auf welche Weise ich die Befehle absetze.

Verfasst: **23.08.2019 14:02:31**

Für mich persönlich gilt, dass die Gefahr, als root einen Fehler zu machen, mit GUI-Programmen sogar geringer ist, weil ich mehr Übersicht habe.
Und außerdem haben die GUI-Programme einen rosa Hintergrund und ein anderes Design, wenn ich als root arbeite. (Ja, ich habe mich vor Jahren mal in einer X-Session als root angemeldet und dort KDE entsprechend eingerichtet.

) Wenn ich noch zusätzlich Fenster als normaler User geöffnet habe (gelber Hintergrund), sehe ich auf den ersten Blick, wem welches Fenster gehört.

Verfasst: **23.08.2019 16:12:56**

Schau auch mal in die manpage von pam_xauth rein,
um also die .Xauthority und $DISPLAY des users zu benutzen, sollte der Eintrag: „session optional pam_xauth.so” in /etc/pam.d/su ausreichen...

Verfasst: **23.08.2019 17:20:42**

KP97 hat geschrieben:
23.08.2019 13:31:20
Wenn ich als root arbeite, dann bin ich mir der Gefahren bewusst.

Das hieße im Umkehrschluß doch, daß ich grafisch als Root das System zerschieße, aber wenn ich auf der Konsole als Root arbeite, kann das nicht passieren?[/quote]Nein. Links root-Fester rechts nicht root ist kein Problem.
Exakt das selbe wenn du dein Kate mit sudoedit startest. Rechts bearbeitest du als root links als User. Auch kein Problem.
Selbes gilt so etwa, wenn du wie Ulidor auf ner 2. TTY dein KDE als root startest. Strg+Alt+F1 User – Strg+Alt+F2 Root oder so.
Matsch wird das erst wenn du 3 KDE-"Programme" startest und die alle zusammen in einem X11 betreibst. Die kommunizieren nämlich alle wild miteinander und plötzlich kann deine Gesandboxte $Unsicheraplikation Mausklicks und Tastatureingaben als root durch führen. Selbst wenn die nicht bösartig ist, kann das mit unter unerwartete Nebenwirkungen haben. Deswegen hat KDE (und andere Bestandteile) da mittlerweile Sperren eingezogen, dass du Programme unter zwei unterschiedlichen Usern laufen lässt.
Und wie reagiert willy4711 da drauf?! Oh starten wir noch ein 2. KDE als root in dem KDE das als User läuft. Und plötzlich kannst du im einen Programm nicht mehr feststellen, wie die die Vorschaubilder dargestellt werden, weil du die ja mit nem anderen User angelegt hast. Und nachdem ihm der Kopf so richtig doll vom gegen die Wand rennen weh tut, meint er, das das nur so schlimm weh tut weil er ja besonders viel Anlauf nehmen musste, weil da irgend welche Bevormunder ne Absperrung vor aufgestellt haben, die man zuerst durchbrechen musste.

Sorry, zwei User in einem X11 tut halt nicht. Das ist keine Bösartigkeit sondern das hat zum Zeitpunkt des Designs einfach keiner im Blick gehabt. Und für Desktop Enviroments, wo die Idee war, dass die Programme alle schön ineinander greifen gilt das noch mehr. Wenn ihr das unbedingt wollt nehmt wayland und irgend welche Standalone Programme. Im allgemeinen gibt es deutlich sinnvollere Wege wie Gnomes admin:// oder KDEs "edit as root". Es gibt einfach keinen erdenklichen Grund warum die Grafikerzeugung als root erfolgen soll. Völlig unter welchem User die GUI-Läuft. Solange es die Daten als root öffnet ist alles bestens.

Was bitte ist daran falsch?

Sobald du ein Programm als root startest haben halt defakto alle anderen auch zugriff auf Tastatur und Maus als Root. Haben damit defakto halt auch root-rechte. Vor allem hast du halt bei den DEs meistens mehrere Abstraktionsebenen. Wenn du ne Datei öffnest macht das nicht das Programm selbst sonder KIO. (Damit du z.B.a auch auf Netzwerkshares zugreifen kannst ohne das in jedes Programm einzeln einzubauen. Das selbe gilt für Gnome und gvfs.) Wenn du jetzt Programme mit unterschiedlichen Usern startest wird das ziemlich wild, als welcher Nutzer jetzt gvfs laufen soll. Wie vom User erwartet läuft des eher so in 50% der Fälle. Gleiches gilt für Passwortmanager oder ähnliches.

Wenn es falsch und unsicher wäre, warum wird es dann in Debian angeboten und teilweise per Installer so vorgegeben.

pkexec nimmt an, dass du weißt was du machst und dich selbst darum kümmerst das nur in Umgebungen zu nutzen, wo es funktioniert. pkexec vim ist völlig unproblematisch.

Verfasst: **23.08.2019 20:11:44**

@wanne
Deine Zitate sind arg durcheinander und daher lassen sich Deine Kommentare auch nicht mehr zuordnen. Sehr wirr das Ganze.
Also ich "KP97" habe auf @Ulidors Beitrag geantwortet, wie auch aus dem Zitat ersichtlich. Ich habe kein KDE sondern Xfce, aber das hatte mit meinem Beitrag nichts zu tun.
Darin ging es allein um die Frage: Grafischer Root oder Konsolen Root. Ich bin nach wie vor der Meinung, daß es dem falschen Befehl egal ist, ob er grafisch oder als Konsolenbefehl abgesetzt wird. Darin waren @Ulidor und ich einer Meinung, daß es mir überlassen sein muß, welche Variante ich wähle, und wie ich das mache.
@Ulidor hat in seinem KDE noch zusätzlich farbliche Unterscheidungen gewählt, ich nutze Spacefm und habe wieder andere Möglichkeiten.
Es steht und stand aber außer Frage, daß ich als Root doppelt aufpassen muß - aber das ist nichts Neues und war schon immer so.
Nach meinen fast 40 Jahren IT habe ich das auch nie anders kennengelernt...auch auf einem Mainframe nicht...

Verfasst: **23.08.2019 21:50:31**

KP97 hat geschrieben:
23.08.2019 20:11:44
Darin ging es allein um die Frage: Grafischer Root oder Konsolen Root.

Und ich habe darauf geantwortet dass ein X11 mit root und user halt Matsch geben wird immer. Du kannst da nicht mehr aufpassen. Wenn das passiert hast du scheiße gebaut.

debianforum.de

GUI-Programme unter KDE als root

GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root

Re: GUI-Programme unter KDE als root