GUI-Programme unter KDE als root

[willy4711]

@ 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*

[willy4711]

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

[guennid]

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?

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

[MSfree]

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.

[KP97]

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.

[Ulidor]

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.

[detix]

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...

[wanne]

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.

[KP97]

@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...

[wanne]

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.

[TomL]

Sorry, zwei User in einem X11 tut halt nicht.

Das verstehe ich.

Bezogen auf Konsole:

Nein. Links root-Fester rechts nicht root ist kein Problem.

Das verstehe ich auch.

Selbes gilt so etwa, wenn du wie Ulidor auf ner 2. TTY dein KDE als root startest

Yep, ist auch klar....

Matsch wird das erst wenn du 3 KDE-"Programme" startest und die alle zusammen in einem X11 betreibst.

Ja, ist verstanden

...aber jetzt.... davor und dahinter eingerahmt von "Auch kein Problem":

Exakt das selbe wenn du dein Kate mit sudoedit startest.

Wieso ist "sudoedit kate" unproblematisch? Kate ist doch ein grafisches Programm und erfüllt damit genau die Vorgaben, ggf. das System zu gefährden, weil man 2 User auf einem X11 hat... eben vor dem Hintergrund, dass sudoedit ja auch nur 'sudo' verwendet. Könntest Du das noch kurz erklären. Mich hat Dein Beitrag und das, was anscheinend im Hintergrund ohne meine Wissen möglich wäre, schon nachdenklich gemacht. Nur das mit der Kate passt da irgendwie nicht rein....

[Ulidor]

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.

Auch dieser Gefahr bin ich mir bewusst, wenn ich als Root in der grafischen Umgebung eines normalen Users arbeite. Aber ganz ehrlich, wie hoch ist denn das Risiko, dass ich Schadsoftware auf meinem System habe? Derzeit benutze ich ausschließlich Pakete aus den offiziellen Debian-Quellen und deb-multimedia. Ich habe mich bisher immer auf die gute Arbeit des Debian-Teams verlassen, und das schon seit einigen Debian-Generationen. Der hohe Komfort, mal eben Dolphin oder Kate als Root aufrufen und damit arbeiten zu können, während ich eigentlich als normaler User unter KDE angemeldet bin, ist mir dieses wohl eher theoretische Risiko wert.

[willy4711]

Ich habe jetzt keine Lust auf das alles einzugehen, was wanne geschrieben hat. Eine Bemerkung sei mir aber erlaubt.
Wenn der User dazu gezwungen wird, für alltägliche Handlungen die Konsole zu benutzen, dann gute Nacht Linux-Desktop.
Aber vielleicht wäre es ja eine Lösung, für Debian, alle DE bis auf Gnome Wayland aus dem Programm zu nehmen.
Nvidia --> wozu braucht man das AMD geht ja auch und gut.
Sicher ist sicher.

@Ulidor
Hab noch was gefunden für einen Editor (Kate /kwrite) unter KDE. Ausprobiert -----> Klappt.
Im Gegensatz zu Debian machen sich halt andere schon Gedanken, wie man solche Probleme lösen kann.
https://www.reddit.com/r/kde/comments/b ... _password/

[wanne]

Wieso ist "sudoedit kate" unproblematisch?

sudoedit führt den grafischen Teil der im X11 hängt weiter als User aus aus und macht lediglich beim beenden ein Copy. Ich verstehe btw. nicht im geringsten warum nicht mehr grafische Programme sowas von sich aus anbieten. Mit Privilege Drop bietet linux eigentlich sogar viel elegantere Sachen. Bei Servern ist das seit Jahren üblich, dass der eigentliche Prozess als User läuft während eventuell die paar Files, die eventuell Rootrechte benötigen als root geöffnet werden.
Ich meine das KDE das auch mal konnte.

[Ulidor]

@Ulidor
Hab noch was gefunden für einen Editor (Kate /kwrite) unter KDE. Ausprobiert -----> Klappt.
Im Gegensatz zu Debian machen sich halt andere schon Gedanken, wie man solche Probleme lösen kann.
https://www.reddit.com/r/kde/comments/b ... _password/

Das funktioniert bei mir mit kate/kwrite ja auch. Aber ich will ja nicht nur einzelne Dateien in /etc bearbeiten. Alles, was mit meiner Systemverwaltung als root zu tun hat (Backup-Skripte und deren Protokolle, Protokolle der Systemänderungen, Skripte für Updates und deren Protokolle...) speichere ich unterhalb von /root. Dafür habe ich als User noch nicht mal Leserechte, was auch gut so ist. Deshalb verwende ich Dolphin unter root und kann von da aus auch kate/kwrite aufrufen.

sudoedit führt den grafischen Teil der im X11 hängt weiter als User aus aus und macht lediglich beim beenden ein Copy. Ich verstehe btw. nicht im geringsten warum nicht mehr grafische Programme sowas von sich aus anbieten. Mit Privilege Drop bietet linux eigentlich sogar viel elegantere Sachen. Bei Servern ist das seit Jahren üblich, dass der eigentliche Prozess als User läuft während eventuell die paar Files, die eventuell Rootrechte benötigen als root geöffnet werden.
Ich meine das KDE das auch mal konnte.

Mit sudoedit kann ich nicht viel anfangen (siehe oben). Mir wäre aber eine Lösung, wie du sie hier beschrieben hast, auch lieber.

[TomL]

sudoedit führt den grafischen Teil der im X11 hängt weiter als User aus aus und macht lediglich beim beenden ein Copy.

Oh, das ist clever... aber wer weiss denn sowas? Ich habe mir gestern abend noch die man-Page angesehen und bin sogar auf den Absatz

1. Temporary copies are made of the files to be edited with the owner set to the invoking user.

gestoßen und habs trotzdem nicht geschafft, im Kopp die richtige Verknüpfung herzustellen.... was mir jetzt erst durch Deinen Hinweis klar geworden ist.

[willy4711]

Das funktioniert bei mir mit kate/kwrite ja auch. Aber ich will ja nicht nur einzelne Dateien in /etc bearbeiten. Alles, was mit meiner Systemverwaltung als root zu tun hat (Backup-Skripte und deren Protokolle, Protokolle der Systemänderungen, Skripte für Updates und deren Protokolle...) speichere ich unterhalb von /root. Dafür habe ich als User noch nicht mal Leserechte, was auch gut so ist. Deshalb verwende ich Dolphin unter root und kann von da aus auch kate/kwrite aufrufen.

Die Protokolle / Skripte unter /root zu speichern, finde ich nun wieder ziemlich schräg. Was hat das für ein Grund?
Sämtliche anderen Protokolle werden doch unter /var/log/ abgelegt ?

Mit Privilege Drop bietet linux eigentlich sogar viel elegantere Sachen. Bei Servern ist das seit Jahren üblich, dass der eigentliche Prozess als User läuft während eventuell die paar Files, die eventuell Rootrechte benötigen als root geöffnet werden.

Die Gretchenfrage ist:
Warum wurde das entfernt, bzw. warum kümmert sich keiner der Entwickler darum?
Das oben von mir verlinkte Skript, erledigt genau die von mir gewünschte Fuktionalität und ist als Service Menü innerhalb von Dolphin aufrufbar,
ohne auf der Konsole rumzuhacken. (naja nur einmal )

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 musst

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.

Verstehe ich nicht. Wenn ich Dolphin als Root öffne, ausschließlich, um Dateien zu löschen / Verschieben oder zu editieren,
weil ich einfachen keinen Bock habe, dies auf der Konsole zu machen

Ich benutze KDE nur noch als "Spielwiese", da es der Funktionalitäten, die ich gerne haben möchte beraubt wurde.
Wie ich schon oben sagte, und du ja auch sagst:
Es gibt Auswege, die anscheinend auch sicher sind. Den Entwicklern von KDE scheint das aber nicht wichtig genug zu sein.
Lieber spielen sie an dem PIM-Zeugs rum, was eh nie richtig funktioniert hat, und den idiotischen Anspruch stellt, alles aber aber auch
alles, was auf dem Desktop geschieht zu erfassen.

Weitere Frage, wäre: Warum beschränken sich diese Sachen weitestgehend nur auf KDE ?
"Verschlafen" die Entwickler der anderen DE's da was (Einschließlich Gnome unter X) oder liegt es an Qt?

Mein "gegen die wand Laufen" in meinem Produktivsystem (Xfce) beschränkt sich auf das gepurgte Sudo und die ausschließliche
Anwendung vom Poicykit. Ist das genauso "unsicher" wie sudo/gksudo/gksu ?. Warum ist es dann implementiert ?

[TomL]

Ich habe jetzt keine Lust auf das alles einzugehen, was wanne geschrieben hat. Eine Bemerkung sei mir aber erlaubt.
Wenn der User dazu gezwungen wird, für alltägliche Handlungen die Konsole zu benutzen, dann gute Nacht Linux-Desktop.
Aber vielleicht wäre es ja eine Lösung, für Debian, alle DE bis auf Gnome Wayland aus dem Programm zu nehmen.
Nvidia --> wozu braucht man das AMD geht ja auch und gut.

Willy, ich denke, man kann das auch entspannt angehen und besser Probleme da angehen, wo Probleme echte Probleme sind.... was das hier jedenfals nicht ist. Das hier ist hier m.M.n. nur ein hausgemachtes Problem, weil man alten Gewohnheiten anhängt... ein Problem was ich beispielsweise auch ohne sudoedit und ohne grafische Programme als root gar nicht habe.

Ich selber würde beispielsweise niemals Änderungen direkt auf produktiven Dateien machen, wenn dafür root-Rechte notwendig wären, weder bei Konfiguration noch für Scripte. Das passiert bei mir z.B. für Scripte alles in einem Server-Verzeichnis mit dem Namen "History", was in dem jeweiligen Sektor für 'alles' gilt. Das Verzeichnis enthält für jedes "Projekt" seine Sourcen, versioniert aufbewahrt, was dann schließlich so aussieht (bis 5.2.8 wars iptables, ab hier nftables):

Code: Alles auswählen

$ ls "/media/Server/Setups/History/usr ! local ! bin/netfilter/nftables/server"
insgesamt 15M
drwxrwx--- 2 thomas thomas    0 2019-08-19 14:49 .
drwxrwx--- 2 thomas thomas    0 2019-07-26 11:43 ..
-rw-r--r-- 1 thomas thomas  22K 2019-01-17 16:41 netfilter.V_5_2_9
-rw-r--r-- 1 thomas thomas  21K 2019-01-17 16:41 netfilter.V_5_3
-rw-r--r-- 1 thomas thomas  21K 2019-01-17 16:42 netfilter.V_5_3_1
-rw-r--r-- 1 thomas thomas  20K 2019-01-21 18:09 netfilter.V_5_4
-rw-r--r-- 1 thomas thomas  20K 2019-01-21 21:51 netfilter.V_5_4_1
-rw-r--r-- 1 thomas thomas  19K 2019-01-28 10:33 netfilter.V_5_4_2
-rw-r--r-- 1 thomas thomas  20K 2019-02-06 16:15 netfilter.V_5_4_3
-rw-r--r-- 1 thomas thomas  20K 2019-02-06 19:14 netfilter.V_5_5
-rw-r--r-- 1 thomas thomas  20K 2019-04-05 21:03 netfilter.V_5_6
-rw-r--r-- 1 thomas thomas  20K 2019-05-30 11:13 netfilter.V_5_7
-rw-r--r-- 1 thomas thomas  20K 2019-07-08 12:14 netfilter.V_5_7_1
-rw-r--r-- 1 thomas thomas  20K 2019-07-21 15:16 netfilter.V_5_8
-rw-r--r-- 1 thomas thomas  20K 2019-07-26 11:02 netfilter.V_5_8_1
-rw-r--r-- 1 thomas thomas  19K 2019-08-22 11:08 netfilter.V_6_0

Die nächste Version wäre 6.0.1, oder 6.1 oder sogar 7.0, je nach Umfang der Änderungen. Die gleiche Historie habe ich auch für Postfix, oder Dovecot, oder Samba, oder Openvpn, etc... und alle mir wichtigen Prozesse, die ich sorgsam warte.
Für Postfix:

Code: Alles auswählen

insgesamt 60K
drwxr-xr-x 2 root root 4,0K 2017-12-18 15:40 .
drwxr-xr-x 7 root root 4,0K 2019-05-02 18:14 ..
-rw-r--r-- 1 root root 1,4K 2017-04-18 14:43 main.cf.V_0_org
-rw-r--r-- 1 root root 2,1K 2017-04-18 15:44 main.cf.V_1
-rw-r--r-- 1 root root 2,3K 2017-05-07 23:44 main.cf.V_2
-rw-r--r-- 1 root root 2,0K 2017-05-08 11:35 main.cf.V_2_1
-rw-r--r-- 1 root root 2,3K 2017-05-08 11:44 main.cf.V_2_2
-rw-r--r-- 1 root root 2,3K 2017-05-08 19:03 main.cf.V_2_3
-rw-r--r-- 1 root root 2,3K 2017-05-09 19:11 main.cf.V_3
-rw-r--r-- 1 root root 3,0K 2017-05-31 12:00 main.cf.V_4
-rw-r----- 1 root smsd 2,9K 2017-11-27 18:24 main.cf.V_4_1
-rw-r----- 1 root root 3,6K 2017-12-20 14:53 main.cf.V_5_0
-rwx------ 1 root root 1,6K 2017-12-02 16:11 refresh-rules.V_1_0
-rwx------ 1 root root 2,3K 2017-12-02 16:11 refresh-rules.V_2_0
-rwx------ 1 root root 2,3K 2017-12-20 16:41 refresh-rules.V_2_1

Änderungen werden immer hier durchgeführt, mit meinen Userrechten, und mit dem Midnightcommander in einem root-Terminal wird dann die bisherige produktive Datei einfach ersetzt, manchmal sogar vorher erst über den Umweg eines Testsystems. Ums kurz zusagen, aufgrund meiner Arbeitsweise käme ich gar nicht in die Situation, grafische Programme mit root-Rechten starten zu müssen. Und zu keiner Zeit entsteht daraus eine Einschränkung oder Behinderung für mich.

Und mal ganz ehrlich, einen grafischen Dateimanager als root ist wirklich so ziemlich das unwichtigste von dem, was man wirklich braucht. Das kann in einem root-Terminal der Midnightcommander sogar deutlich effizienter und schneller und unkompliizierter, wenn man sich mal wieder die Effektivität der Tastatur und Hotkeys bewusst gemacht hat.

Ich sags ja immer schon, im Grundegenommen ist es die von Windows geprägte Arbeitsweise des Users, die maßgeblich gefährdend für ein System ist. Grafische Programme mit root-Rechten ist nur ein beliebiger Aspekt davon, sudo ein anderer, bei den buntu-Derivaten die ppa's, bei Mint gefährliches Halbwissen, was hartnäckig verteilt wird.... letztendlich ist es die Summe all dessen, die sich im Userverhalten manifestiert und schließlich dafür verantwortlich ist, die Sicherheit eines Systems zu kippen. Zum jetzigen Zeitpunkt halte ich das noch für unkritisch... wenn Linux allerdings mal richtig in den Fokus der Crime-Scene geraten sollte, wird sich das Bild ändern.

jm2c

[Ulidor]

Die Protokolle / Skripte unter /root zu speichern, finde ich nun wieder ziemlich schräg. Was hat das für ein Grund?
Sämtliche anderen Protokolle werden doch unter /var/log/ abgelegt ?

Meine Skripte, Protokolle und sonstige als root erstellte Dateien sind ja keine Systemdateien und ich möchte gerne alles übersichtlich an einem Ort haben. Da bietet sich /root an, weil ich dann ja auch root bin. Und ich kann mir da sicher sein, dass das System nicht aus irgendwelchen Gründen mal was löscht.

[guennid]

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# [Editor]/gparted

funktioniert unter meiner Installation (s.o.), also unabhägig von der gewählten GUI. Danke!

Gehe ich recht in der Annahme, dass du einen Schritt ausgelassen hast?

Mit

Code: Alles auswählen

su -

bin ich erstmal in /root, ich musste also noch das Verzeichnis nach /home/[user] wechseln.

Es empfiehlt sich also

Code: Alles auswählen

su -

unter buster nicht zu verwenden. (Welchen Sinn hat dann eigentlich noch dieses eben erst eingeführte Kommando, wenn root unter der User-GUI doch nichts machen darf?) Man muss sich dafür was Eigenes scripten - richtig?

Grüße, Günther

[MSfree]

Gehe ich recht in der Annahme, dass du einen Schritt ausgelassen hast?

Richtig, export DISPLAY... hat gefehlt.

Es empfiehlt sich also

Code: Alles auswählen

su -

unter buster nicht zu verwenden.

Du kannst auch su ohne Minus verwenden, nur wird dann dir Umgebungsvariable PATH anders gesetzt als mit "su -". Diese Unart seit Buster läßt sich aber auch auf das alte Verhalten zurücksetzen, indem man die Datei /etc/login.defs anpaßt und die Zeile:

Code: Alles auswählen

ENV_SUPATH	PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH	PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

sucht und dort die Zeile

Code: Alles auswählen

ALWAYS_SET_PATH yes

dahinter hängt.

Meine Wiki auf meinem persönlichen Server wird immer länger mit Anpassungsarbeiten, die nach eine Neuinstallation durchzuführen sind.

(Welchen Sinn hat dann eigentlich noch dieses eben erst eingeführte Kommando, wenn root unter der User-GUI doch nichts machen darf?)

Das Minus wurde nicht neu eingeführt, "su -" gibt es solange es su gibt (> 30 Jahre), wurde bisher aber erst ab Buster wirklich "interessant". Der Sinn ergibt sich mir auch nicht, es wird von "Kompatibilität" in Internet gefaselt, wobei das Verhalten sich ja eigentlich erstmal komplett inkompatibel zu sämtlichen bisherigen Unixen und Linuxen ist. Auch Sicherheitsgründe sind hier nicht gegeben, denn Umgebungsvariablen sind zwar unter Umständen unsicher, aber die kann der geneigte Hobbycracker auch selbst auf der kommandozeile setzen, also Sicherheitsgewinn = NULL.

Interressanterweise liefert bei mir nach eine su die Umgebungsvariablen:

Code: Alles auswählen

DISPLAY=:0
XAUTHORITY=/tmp/xauth-1000-_0

womit es dann auch ohne Umschweife möglich ist, graphische Programme als root auszuführen.

Mit "su -" fehlen die beiden Variablen in der root-Umgebung, sie müssen als manuell gesetzt werden.

[guennid]

ALWAYS_SET_PATH yes

Bringt eine nervige Fehlermeldung beim Booten, die aber, wenn ich das Bug-System richtig lese, vernachlässigbar sein soll. Es bleibt: Es nervt.

Grüße, Günther

[MaGe]

Bringt eine nervige Fehlermeldung beim Booten, die aber, wenn ich das Bug-System richtig lese, vernachlässigbar sein soll. Es bleibt: Es nervt.

dann setzte den PATH in /etc/environment


gruss MaGe

[guennid]

dann setzte den PATH in /etc/environment

Hmm, ich bin unsicher, was ich damit anrichte. Ändere ich, wie von MSfree angeregt, /etc/login.defs, dann kriegt nach meinen Beobachtungen (egal ob per „su“ oder „su -“) nur root den geänderten PATH. Trage ich den root-PATH in /etc/environment ein, dann hat ihn auch der user - richtig?

Grüße, Günther

[MaGe]

@ guennid

Ich bin alleiniger nutzer des PCs!.

[...] Kurzanleitung

Für die Eiligen, die nur das System zum Laufen bringen müssen, können Sie Folgendes tun:

Legen Sie alle globalen Umgebungsvariablen, dh diejenigen, die alle Benutzer betreffen, in / etc / environment ab

Denken Sie daran, dass diese Datei von PAM und nicht von einer Shell gelesen wird. Sie können hier keine Shell-Erweiterungen verwenden. ZB MAIL = $ HOME / Maildir / funktioniert nicht![...]


https://translate.google.com/translate? ... rev=search


gruss MaGe