staging.inyokaproject.org

noisefloor schrieb:

Hallo,

kann mal jemand mit mit einem *buntu, was standardmäßig auf GTK setzt und OOTB GVFS an Bord hat testen, ob standarddateimanager admin:///etc/fstab funktioniert?

Das funktioniert hier in einer Ubuntu-Jammy-VM wie folgt:

• Ich gebe im Terminal nautilus admin:///etc/fstab ein.

• Es folgt eine grafische Passwortabfrage

• Nautilus wird geöffnet, und hebt im Ordner /etc die fstab hervor. Außerdem steht in der Adresszeile "Administratoren-Wurzelordner / etc"

• sudo ps -aux | grep admin: zeigt:

  jammy       2302  3.1  1.9 749124 79260 pts/0    Sl+  12:56   0:04 nautilus admin:///etc/fstab

• Mit einem Doppelklick auf die fstab öffnet sich diese in gedit nachdem nochmals das Passwort grafisch abgefragt wird. In der Titelleiste von gedit steht oben fett fstab und darunter steht "admin:///etc"

• sudo ps -aux | grep gedit zeigt

  jammy       2404  1.9  2.2 604892 90420 ?        Sl   12:57   0:00 /usr/bin/gedit --gapplication-service

• Änderungen in der fstab innerhalb des so geöffneten gedit können ohne weitere Passwortabfrage gespeichert werden.

LG, Newubunti

EDIT:

Was vielleicht noch wichtig ist und eventuell auch Dein Hauptanliegen war: Ich kann mit dem so gestarteten nautilus in jedes Verzeichnis - also auch oberhalb von /etc - wechseln und auch überall Ordner anlegen, Dateien bearbeiten (jeweils nach PW-Abfrage) etc..

Also es läuft zwar einerseits im GVFS-admin-Kontext (admin:\\\ ) aber es ist nicht auf die fstab beschränkt. Wundert mich jetzt einerseits nicht, aber hätte man ja vielleicht auch erwarten können.

EDIT2:

Halt stop! Das habe ich unter dem ersten Edit nicht richtig getestet!

Wenn ich in Nautilus in der Adresszeile auf "Administratoren-Wurzelordner" klicke, dann kann ich verfahren, wie oben im ersten Edit beschrieben.

Klicke ich dagegen einfach in der Navigationsleiste links auf "Rechner", dann verliere ich die Admin-Rechte und kann nur noch schreibgeschützt Dateien öffnen.

noisefloor schrieb:

[…]Hallo,

kann mal jemand mit mit einem *buntu, was standardmäßig auf GTK setzt und OOTB GVFS an Bord hat testen, ob standarddateimanager admin:///etc/fstab funktioniert?

Da ist vielleicht ein Missverständnis: Der Dateimanager navigiert durch Ordner, ein Editor öffnet Dateien.

Jedenfalls funktioniert bei mir

nautilus admin:///etc 

wie gewünscht: Es öffnet sich ein neues Fenster für /etc/ und in diesem kann ich mit Root-Rechten navigieren, insbesondere auch in Unterordner, die nur root zugänglich sein sollen. Wenn ich hier eine Datei zum Öffnen anklicke, für die mein normaler Benutzer keine Rechte hat, wird das Passwort erneut abgefragt und dann wird die Datei von gedit mit dem admin-Protokoll geöffnet. Sowohl das Nautilus-Fenster als auch gedit laufen dabei unter meinem normalen Benutzer, nicht als root, aber Dank admin-Protokoll kann ich Arbeiten wie root.

Der ganze Kram ist bei Nautilus nicht nur per Terminal, sondern auch per Kontextmenü zugänglich.

Das gilt für Nautilus. Andere Dateimanager, insbesondere Caja und Nemo arbeiten unter der Haube wohl anders. Ich kämpfe weiter.

Hallo,

sorry, mein letzter Post hat 1,5 Fehler...

1. Ich wollte standardeditor admin:///etc/fstab schreiben (nicht Dateimanager).

2. *buntu meinte ich die Derivate wie Xubuntu, Ubuntu Mate, Ubuntu Budgie und Lubuntu. Also die, die wie Ubuntu auf GTK setzen. Bei Ubuntu funktioniert das, das habe ich selber getestet.

Gruß, noisefloor

Newubunti schrieb:

... Außerdem steht in der Adresszeile "Administratoren-Wurzelordner / etc"

Bei mir nicht, siehe Bild.
Es kann einem also leicht passieren, dass wenn man das Fenster nach einer gewissen Zeit wieder benutzt, dass man vergessen hat, dass man es mit admin:// geöffnet hat. Wenn man dann nach /home/user/... "surft" erzeugt man dann dort Root-Objekte.

Ich kann mit dem so gestarteten nautilus in jedes Verzeichnis - also auch oberhalb von /etc - wechseln und auch überall Ordner anlegen, Dateien bearbeiten (jeweils nach PW-Abfrage) etc..

Neue Ordner und Dateien anlegen, kopieren etc. geht auch ohne weitere PW-Abfrage, auch in /home/user/..., und die gehören dann root.

kB schrieb:

Der ganze Kram ist bei Nautilus nicht nur per Terminal, sondern auch per Kontextmenü zugänglich.

Oh, wie geht das? Bei mir kann das nur Nemo, in Nautilus habe ich nur "Im Terminal öffnen".

UlfZibis schrieb:

[…] kB schrieb:

Der ganze Kram ist bei Nautilus nicht nur per Terminal, sondern auch per Kontextmenü zugänglich.

Oh, wie geht das? Bei mir kann das nur Nemo, in Nautilus habe ich nur "Im Terminal öffnen".

Paket nautilus-admin bringt die Bedienoberfläche. Für Caja gibt es caja-admin, was aber bereits als Standard installiert wird. Bei Nemo ist es wohl direkt eingebaut.

Das betrifft jeweils nur die Bedienoberfläche! Wie es unter der Haube funktioniert, ist jeweils unterschiedlich. Bei Nemo und Caja laufen dann Dateimanager und Editor unter root, bei Nautilus unter dem normalen Benutzer.

kB schrieb:

Paket nautilus-admin bringt die Bedienoberfläche.

War das bei Dir unter Jammy vorinstalliert? Denn bei mir ist das in einer Standard-Ubuntu-Installation nicht vorinstalliert - kann aber natürlich nachträglich installiert werden.

Nur, damit wir nicht aneinander vorbeireden.

LG, Newubunti

noisefloor schrieb:

1. Ich wollte standardeditor admin:///etc/fstab schreiben (nicht Dateimanager).

2. *buntu meinte ich die Derivate wie Xubuntu, Ubuntu Mate, Ubuntu Budgie und Lubuntu. Also die, die wie Ubuntu auf GTK setzen. Bei Ubuntu funktioniert das, das habe ich selber getestet.

Bei einem Standard-XJammy funktioniert das nicht. Beim Aufruf von mousepad admin:///etc/fstab erscheint sofort die Meldung:

Mousepad: Das Dokument konnte nicht geöffnet werden. Der angegebene Ort ist nicht eingehängt.

Es funktioniert pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY mousepad /etc/fstab. Mousepad läuft dann als Root, öffnet die /etc/fstab. Im Mousepad-Fenster wird ein roter Balen angezeigt:

Achtung: Sie verwenden das Systemverwalterkonto und könnten Ihr System beschädigen.

LG, Newubunti

Hallo,

Newubunti schrieb:

Bei einem Standard-XJammy funktioniert das nicht. Beim Aufruf von mousepad admin:///etc/fstab erscheint sofort die Meldung:

Ok, thx. Die Meldung bekomme ich auch. Was dann wohl auch heißt, dass der Standardeditor von Xubuntu nicht mit der GVFS-Schnittstelle umgehen kann.

Gruß, noisefloor

kB schrieb:

Paket nautilus-admin bringt die Bedienoberfläche.

Das ist ja echt ein Super-Tipp. Jetzt wundert es mich aber echt, warum das so lange gedauert hat, bis der hier aufpoppt. Auch hier wird er nicht erwähnt.

Also kann man auch darüber den "Königsweg" beschreiten.

Newubunti schrieb:

Außerdem steht in der Adresszeile "Administratoren-Wurzelordner / etc"

Aber auch nach Installation von nautilus-admin sehe ich das nicht. Liegt vielleicht daran, dass ich es auf einem 18.04 getestet habe. Seit 20.04 habe ich nur noch Nemo, da möchte ich mir jetzt keinen Nautilus reinfrickeln.

Newubunti schrieb:

Bei einem Standard-XJammy funktioniert das nicht. Beim Aufruf von mousepad admin:///etc/fstab erscheint sofort die Meldung:

Mousepad: Das Dokument konnte nicht geöffnet werden. Der angegebene Ort ist nicht eingehängt.

Es funktioniert pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY mousepad /etc/fstab. Mousepad läuft dann als Root, öffnet die /etc/fstab. Im Mousepad-Fenster wird ein roter Balen angezeigt:

Achtung: Sie verwenden das Systemverwalterkonto und könnten Ihr System beschädigen.

Ah, dann läuft dass unter Xubuntu mit Mousepad genauso wie unter Budgie, Cinnamon und Unity mit Nemo. Auch Thunar kennt den Warnbalken.
Den roten Balken finde ich auf jeden Fall sicherer, im Sinne von "Warnung vor Fehlbedienung", als die unauffällige Erscheinung von Nautilus und Gedit.

Jetzt frage ich mich aber, warum gleich 4 Ubuntu-Derivate und Linux-Mint diesen Weg "GUI unter Root" ohne admin:// anbieten, wenn der doch so gefährlich ist.

Hallo,

Jetzt frage ich mich aber, warum gleich 4 Ubuntu-Derivate diesen Weg "GUI unter Root" ohne admin:// anbieten, wenn der doch so gefährlich ist.

Wenn du die Antwort gefunden hast → gerne hier posten. Tipp für deine Wahrheitsfindung bzw. deinen Weg zur Erhellung deiner z.Zt. abgedunkelten Wissenslücken: pkexec hat nichts mit "anbieten" zu tun, das funktioniert grundsätzlich mit allen Programmen so. Steht auch exakt so im Wiki. Tipp 2: admin:// aus GVFS setzt im Hintergrund ebenfalls auf PolKit.

Gruß, noisefloor

noisefloor schrieb:

Ok, thx. Die Meldung bekomme ich auch. Was dann wohl auch heißt, dass der Standardeditor von Xubuntu nicht mit der GVFS-Schnittstelle umgehen kann.

Zu der Begründung kann ich Dir nichts sagen.

Was ich noch sagen kann ist, dass es für thunar kein Paket der Art thunar-admin gibt.

Ich habe hier im Moment eine Multiboot-VM wegen der GRUB-Überarbeitung. D.h. ich kann Dir relativ schnell etwas zu einem *buntu an Standard-Verhalten liefern - aber ohne weitere Begründung.

LG, Newubunti

Newubunti schrieb:

Was ich noch sagen kann ist, dass es für thunar kein Paket der Art thunar-admin gibt.

Man kann da eine custom action basteln. So geöffnet zeigt sich dann ebenfalls ein farbiger Warnbalken: https://www.youtube.com/watch?v=S7xqVHNYa5Q

UlfZibis schrieb:

Jetzt frage ich mich aber, warum gleich 4 Ubuntu-Derivate und Linux-Mint diesen Weg "GUI unter Root" ohne admin:// anbieten, wenn der doch so gefährlich ist.

Das liegt vermutlich daran, das viele einen Weg erzwingen wollen. Ich habe mich auch gefragt, wieso die PolKit Sicherheitslücke in Kubuntu 22.04 reaktiviert wurde — kam daher, das Krusader das für den Rootmodus braucht.

Ist das sinnvoll? Nein. Aber eine Distribution ist auch immer ein Gemeinschaftsprojekt und wenn nur genug danach Schreien (sprich, sich an den Bugreports beteiligen), dann kommen auch quick-and-dirty-Lösungen ins System. Ist ja auch nur universe, da können die Paketbetreuer „machen, was sie wollen“.

Und wie bereits erwähnt, das Umstellen des XServers läuft seit Jahren und es müssen erst sichere Wege für den Umgang mit Rootrechten gefunden werden. Mit GUI ist das eben sehr problematisch, weswegen da viel Altlast mitgeschleppt wird.

Ich bin mit meiner Überarbeitung fertig und stelle sie zur Diskussion.

Hallo!

Was mir aufgefallen ist:

Bevor man in die Rolle Root wechselt, alle Dateien schließen, die nicht unbedingt geöffnet bleiben müssen, alle nicht benötigten Dateisysteme abmelden (umount), und alle nicht benötigten, entfernbaren Datenträger entfernen.

Link korrigieren zu [:mount:umount].

Die Arbeitsumgebung für Root so gut wie irgend möglich von der Arbeitsumgebung anderer Benutzer isolieren. Dies betrifft auch Anzeigeserver wie X11 und Wayland, Kommunikationswege wie D-Bus, sowie gemeinsam genutzte Dienste, Programme, Dateien und Ordner.

[:D-Bus:] verlinken

… Tasten Strg + ⇧ + F1 bis Strg + ⇧ + F6 erreichbaren virtuellen Terminal

Evtl.: Verlinken mit [:Terminal#Virtuelle_Konsole:]

Home-Verzeichnis zerschossen

Link auf [:Homeverzeichnis#Rechte:]

Inhaltlich:

su root: Das ist sowohl bequemer als auch weniger sicher.

Warum? Ich würde auch su - (su --login) nehmen, damit es eine Loginshell für root wird.

Neuere Versionen von Kubuntu ab 18.04 sind …

Der Teil kann raus. Alles einschließlich Kubuntu 20.04 ist bereits EOL, es reicht also „Unter Kubuntu“ oder „Seit 18.04“.

Klasse geschrieben und schön ausführlich und umfangreich! Ich meine im Nachhinein das Gefühl gehabt zu haben, das der Unterschied zwischen pkexec und sudo nicht ganz klar wird, aber dafür gibt es ja die weiterführenden Artikel.

Was die Verlinkungen angeht: Ich denke es wäre gut dies untereinander zu verknüpfen, damit bspw. Bearbeiter des Artikels Homeverzeichnis bei Änderung des Abschnitts Rechte auch den hiesigen Artikel mitändern können. Crosslinken also auf Neudeutsch.

Da viele Nutzer unbedarft sind, wäre vielleicht ein „tl;dr“ noch gut, um auch die lesefaulen Nutzer abzuholen. So nach dem Motto „GUI-Anwendungen fragen von alleine nach dem Passwort → niemals mit sudo starten → konkrete Details finden sich im weiteren Verlauf des Artikels“. Ist aber optional und kommt eher aus den Supportforen-Erfahrungen denn von meiner Einstellung das sowas da stehen sollte 😉