GUI-Programme unter KDE als root

[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

[guennid]

Alleiniger Besitzer des Klapprechners bin ich schon, aber ich bemühe mich trotzdem meine eigenen Konfigurationen möglichst wenig systemstörend vorzunehmen.

Meine Vermutung scheint unbegründet: Nach Eintrag des root-Path in /etc/environment und einem Reboot sehe ich das hier im Benutzer-Terminal:

Code: Alles auswählen

[user]@t42:~$ echo $PATH
/home/[user]/.system/batch:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
thekla@t42:~$ su
Passwort: 
root@t42:/home/[user]# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
exit
[user]@t42:~$ echo $PATH
/home/[user]/.system/batch:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Außerdem macht der Eintrag in /etc/environment den Bohai mit:

Code: Alles auswählen

# export  XAUTHORITY=~[user]/.Xauthority 
export DISPLAY=:0

wieder überflüssig.
Hat jemand eine Erklärung für Dumme?

Grüße, Günther

[MSfree]

Hat jemand eine Erklärung für Dumme?

su übernimmt die Umgebungsvariablen des Benutzers und setzt im Prinzip nur die effektive User-ID auf Null, also die ID von root. Alte su-Implementierungen haben dann noch die PATH-Variable um /sbin und /usr/sbin erweitert.

su - löscht alle Umgebungsvariablen des Benutzers und setzt nur die Umgebungsvariablen für root, die bei einem Konsolenlogin gesetzt werden.

Welche Umgebungsvariablen gerade gesetzt sind, erfährst du, wenn du

Code: Alles auswählen

export

auf die Kommandozeile tippst. Die für die graphische Ausgabe zuständigen Variablen lauten DISPLAY und XAUTHORITY und werden vom Desktop für den Benutzer eingerichtet. Diese beiden sind nach eine su - verschwunden (siehe oben), folglich kann man keine graphischen Programme mehr als root ausführen, bis man sie manuell setzt. Mit su werden die benutzerdefinierten Umgebungsvariablen auf den root-Prozeß vererbt. Der normale Benutzer hat aber in der Regel keine PATH auf /sbin und /usr/sbin, weswegen so Programme wir shutdwn, ifconfig ... nicht mehr in dieser Umgebung gefunden werden (es sei denn man erweitert den PATH manuell oder ruft die Programme mit Absolutpfad auf).

[guennid]

Ergo kann man so vorgehen: Denn Root-PATH in /etc/environment schreiben, "su -", DISPLAY, XAUTHORITY vergessen und wie bis stretch gewohnt mit "su" arbeiten?

Mann, Mann, Mann!!! Ich habe ja nun mal keine höheren Weihen, strebe auch keine solchen an und weiß insofern nicht, ob ich diese Änderungen in buster für verrückt halten darf.

Danke für die Erklärungen!

Was ich noch nicht recht verstehe ist: Wieso kriegt der Benutzer nicht den Root-PATH aus /etc/environment? Sehe ich recht, dass dafür folgende Konfiguration verantwortlich ist: im home des users habe ich in .profile einen PATH für diesen eingetragen und der überschreibt dann den in /etc/environment? Erzeugte ich jetzt einen neuen User und trüge keinen PATH in dessen .profile ein, kriegte der den Root-PATH?

Grüße, Günther

[KP97]

@Günther
/etc/environment ist global, wird aber von Einträgen in Deinem Home überschrieben, weißt Du doch.
Übrigens hatte ich dieses "su - Verhalten" schon vor Monaten beschrieben, als es in Sid auftauchte, und auch die Lösungsmöglichkeiten, wie man das alte Verhalten wieder herstellen kann. Von @Blackbox wurde ich deswegen noch angegangen, ich möge doch diese "Frickelei unterlassen" ...na ja....halt Blackbox...
Ich suche das jetzt nicht heraus, der Thread wurde aber des öfteren verlinkt, evtl. fällt er Dir ja noch gelegentlich in die Hände.

[MSfree]

Ergo kann man so vorgehen: Denn Root-PATH in /etc/environment schreiben, "su -", DISPLAY, XAUTHORITY vergessen und wie bis stretch gewohnt mit "su" arbeiten?

Ja, warum auch nicht? Das ist genauso eine gültige Alternative wie das Setzen von ALWAYS_SET_PATH yes in login.defs (wobei ich die Warnung beim Booten nicht wirklich schlimm finde).

Was ich noch nicht recht verstehe ist: Wieso kriegt der Benutzer nicht den Root-PATH aus /etc/environment?

Das hängt mit der Reihenfolge zusammen, in der die Shell die Dateien /etc/environment, /etc/profile, /etc/bash.bashrc, ~/profile und ~/.bashrc abarbeitet, wobei die zuletzt geladene vorher gesetzte Werte überschreiben kann. Noch dazu kann man die Shell auch als Nicht-Loginshell starten, so daß hierbei (vermutlich) nur die /etc/environment geladen wird.

su - statrtet eine Bash als Loginshell mit einer neuen Umgebung.
su statet eine Bash als Nich-Loginshell und erbt somit die Benutzerumgebung.

[guennid]

Ich suche das jetzt nicht heraus, der Thread wurde aber des öfteren verlinkt, evtl. fällt er Dir ja noch gelegentlich in die Hände.

Das ist nicht nötig, den (oder einen anderen) hatte ich bereits damals zur Kenntnis genommen, aber nicht weiter beachtet, weil mir nur die PATH-Geschichte im Gedächtnis zu halten als wichtig erschienen war und ich dagegen auch nichts einzuwenden hatte - ich folglich durchaus bereit war, mich an "su -" zu gewöhnen. (Man lässt sich ja nicht gerne immer wieder der "Ewiggestrigkeit" zeihen ) Dass das dann diese XAUTHORITY, DISPLAY-Geschichte nach sich zöge, hatte ich nicht auf dem Schirm.

Meine gegenwärtige Einschätzung von „su -“: Der Berg kreißte - und gebar eine Maus!

Am Rande interessieren würde mich jetzt, inwiefern dieser letzte Threadteil für die DEler der verschiedenen Couleurs sich auswirkt. Dürfen die sich trotzdem noch mit pkexec und policykit rumschlagen?

Grüße, Günther

[detix]

Bin mir nicht sicher ob der Post hier nur untergegangen oder völliger Blödsinn ist, aber warum macht ihr das nicht so:
viewtopic.php?p=1215101#p1215101

[guennid]

Der Post dürfte wohl im Gemenge mit wannes wortgewaltigen Beiträgen untergegangen sein. Ich hab's jetzt ausprobiert und kann sagen: Funktioniert! Die Methode nötigt allerdings dazu „su -“ zu benutzen. Das PATH-Problem beim su-Kommando löst sie nicht. Insofern erscheint mir die Methode /etc/environment einfacher. Es sei denn, man zeigt mir nachvollziehbar, dass sie unsicherer ist.

Und was das Ganze hier jetzt noch mit irgendwelchen Desktop-Umgebungen, respektive systemd--> policykit zu tun haben könnte (was ja, soweit ich es überblicke, der Ausgangspunkt der Diskussion war), erschließt sich mir immer noch nicht.

Am Rande erwähnenswert für mich: man pam.xauth und auch /etc/pam.d/su setzt sowohl einige Vertrautheit mit IT-Sprech als auch entsprechende Sachkenntnis voraus. Da dieses merkwürdige Kürzel „pam“, das für mich mit Alltagsenglisch nicht zu entschlüsseln ist, mir aber in letzter Zeit immer wieder auf die Füße fällt, habe ich mal versucht, hier (1) meine Unwissenheit ein wenig abzubauen.
(1) https://linuxwiki.de/PAM

Grüße, Günther