staging.inyokaproject.org

Newubunti schrieb:

Mir geht es hier um eine möglichst leicht verständliche sauber differenzierte Darlegung der Problemlage - möglichst auch anhand von ein paar Praxisbeispielen.

Ich glaube dafür gibt es gerade unter so „vollgepackten“ Distributionen wie Ubuntu viel zu viele Abstraktionen. Ich würde da vielleicht nicht näher auf die Details eingehen und das Zusammenspiel zwischen den Layers im Kernel, Diensten wie AppArmor, Sandboxen wie Snap, die mühlselige Arbeit xorg von root wegzuprogrammieren, etc. pp, da du sonst von leicht verständlich und sauber differenziert schnell weg kommst.

…klare Unterscheidung zwischen Problem für die Systemstabilität und Problemen für die Systemsicherheit

Das kannst du nicht klar trennen, weil bspw. das Überschreiben von Speicherbereichen (was der aktuelle Kernel schon sehr gut verhindert) beides ist, ebenso wie das Überschreiben von Dateien.

Weil bei diesem Thema ist es zunächst schon mal wichtig, dass klar und unmissverständlich dargestellt wird, wie es richtig und sagen wir noch besser, so sicher wie möglich gemacht wird.

Das ist recht einfach. Das System weist dich per PolicyKit darauf hin, wenn explizit erweiterte Rechte (egal ob root oder anderer Nutzer) gefordert werden.
Als root muss man eigentlich nur beim Einrichten des Systems arbeiten. Alles weitere ist von PolicyKit abgedeckt. Unter Ubuntu lässt sich das vermutlich alles über PK bewerkstelligen, müsste ich mal wieder ausprobieren.

Darüber hinaus kann es natürlich Sonderfälle geben, wobei die auch über den normalen Nutzer hinaus gehen. Ich lese bspw. auch oft sudo dmesg. Eigentlich wurde dmesg für den Nutzer unlesbar gemacht, weil systemd werkelt und dieser journalctl -k nutzen soll, welches mit dem Hauptbenutzer funktioniert.

statt

sudo -H nano DATEI 

im Wiki empfehlen? Das hat ja auch den Vorteil, dass es universeller ist.

+1

dann kommt der Anwender, wie auch immer, auf die Idee einen grafischen Editor mit Rootrechten zu öffnen - was z.B. wenn man wie für gedit suchmaschinelt (Keywords: "run gedit as root") - zu diesem Ergebnis ziemlich weit oben führt,

https://help.gnome.org/users/gedit/stable/gedit-edit-as-root.html.en

Ich kenne gedit nicht, aber vielleicht hat gerade das Programm ja durch die damalige Loginproblematik die Rootrechte geschickt abgefangen. Müsste man im Quellcode schnuppern, was da genau passiert. Aber selbst wenn es mit gedit ginge, ist das nicht auf jedes Programm übertragbar, nicht mal auf jedes GTK4-Programm.

Und nein, daraus leite ich nicht ab, dass man sudo -H gedit /etc/default/grub könne man ruhig auch machen.

Kann man. Wenn was schiefgeht, muss man sich aber zu helfen wissen, wie generell beim Editieren systemweiter Dateien.

Ich glaube der Einsatz von Rootrechten liegt auch oft daran, das ein Thema nicht gelesen wird. Das allermeiste lässt sich über einfache Benutzer und Gruppen so einrichten, das man keine Rootrechte mehr braucht. Für die alten Hasen ist das aber auch nicht leicht, da root bequem ist. Ich schmeiße ein su - in die Konsole und kann von da aus bequem alles machen, auch ein su - Nutzer ohne Passwort, weswegen viele meiner „Servicebenutzer“ nicht mal ein Passwort haben, die dienen nur dazu die Prozesse zu trennen. Mache ich auch heute noch so. Gut, unter Ubuntu müsste ich sudo -i nutzen.

Deswegen denke ich, der Artikel sollte grundsätzlich davon abraten irgendwas mit Rootrechten zu machen, wenn sie nicht wirklich zwingend gebraucht werden, wie zum Einrichten neuer Festplatten oder sowas. Und wenn man diese dann braucht, sollte man konkret wissen wofür und was man da macht. Wer sich im System auskennt, der macht eh, was er will 😉

Was die grafische Umgebung angeht:

• GNOME: admin:///

• Plasma: Normal arbeiten, Anfrage kommt beim Speichern.

• sudoedit

Darauf sollte der sich beschränken. Für „erweiterten Umgang mit Rootrechten“ kannst du ja deinen Unterartikel schreiben.

ChickenLipsRfun2eat schrieb:

Inwiefern? Wie das technisch funktioniert? Wie man das manuell nachstellen kann? Finde ich für den Artikel irrelevant. Du kannst aber sowas wie

cp /etc/fstab /tmp/
gedit /tmp/fstab
sudo mv /tmp/fstab /etc/fstab

verwenden, um ein ähnliches Verhalten zu erreichen.

Wenn ich mich nicht ganz schlimm irre, führt das aber zu falschen Besitzverhältnissen und Rechten für die Datei /etc/fstab.

Im Prinzip geht es doch hier im wesentlichen um die Bearbeitung von Systemdateien mit geringstmöglichem Risiko, oder sehe ich das falsch?

Sehe ich auch so. Dafür gibt es in jeder Umgebung Wege.

Und in einem Artikel der da heißt "mit Root-Rechten arbeiten" sollten IMHO alle möglichen Wege zusammengefasst aufgezählt werden (mit entsprechenden Hinweisen bzgl. Risiko etc.).
Wird das unterlassen, wird – vor allem der Einsteiger – "kreativ" und probiert so Sachen wie sudo nautilus. Was dann kommt, kennen wir ... Forumsanfragen wie: "Einstellungen in Nautilus werden nicht gespeichert". Ich muss zugeben, dass auch mir das anfangs passiert ist. Dann wurde zunächst gksudo empfohlen bis sich dann irgendwann sudo -H als einigermaßen komfortable und zumindest gangbare Weise herausstellte, ich den "Königsweg" mittels Nemo aber selbst entdecken musste.

… zwischen Sicherheit und Systemstabilität hin und her geschleudert wird…

Ich habe die Sicherheit bislang außen vor gelassen.

Danke dass Du das mal klärst. Umso weniger verstehe ich, warum in dieser Diskussion immer wieder mit dem (Totschlag-)Begriff "Sicherheit" argumentiert wird.

Es ist logisch, das grafische Anwendungen mit Rootrechten stets Vollzugriff aufs System haben und damit alles und unter allen Benutzern manipulieren können und das somit eine Sicherheitskatastrophe ist.

Hier schon wieder das Sicherheitsargument, warum? Wenn ich mit sudo nano oder sudo mv (siehe oben) einen Fehler mache, habe ich als Resultat doch dasselbe "Sicherheitsproblem".

Ich habe mich auf die Stabilität beschränkt, die beeinträchtigt wird, da root keine grafische Umgebung hat und somit die des Nutzers übernimmt.

Wenn das generell zu einem solchen Problem führt, sollte das IMHO als Bug behandelt werden, und nicht als "Fehlbedienung" des Nutzers. Es ist nun mal offiziell so vorgesehen, dass wenn ich Programme wie Synaptic oder GParted aufrufe, ich zu anfangs nach dem Passwort gefragt werde, und ab da die graphische Anwendung dann unter root läuft. Was soll daran falsch sein? Und Nemo bietet "Als Systemverwalter öffnen" nun mal auch offiziell an. Also muss ich doch davon ausgehen dürfen, dass das ein erlaubter, sicherer und stabiler Weg ist. Wenn nicht, ist das eindeutig ein Bug.

Der Weg funktioniert noch, ist aber auch nur ein Workaround (siehe https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/626), daher auch die XWayland-Komponente. Das wird so lange bestehen, bis die meisten Programme sich auf die Trennung zwischen GUI und Rechten eingestellt haben (Verwendung eines daemons, separate Executables,…).

Und Du gehst davon aus, dass Nemo dann nicht zu den "meisten Programmen" gehören wird? Wo nimmst Du das her? (Seit 1972 heißt es schon, das Erdöl geht in 10 Jahren aus.)

Wie geht das, also wie soll ich im mit sudo -H gestarteten GUI-Fenster dessen Umgebungsvariablen anzeigen lassen?

Z.B. wenn das Programm das über dessen debugging kann, prinzipiell die Ausführung von env, das alle exportierten Variablen auflistet. Alternativ und genauer wäre das mit Debuggern wie GDB.

Dachte ich mir doch, dass das etwas komplizierter ist. Und bis dahin – also bis mir jemand das Gegenteil beweist – gehe ich davon aus, dass sich die Entwickler von Nemo ausreichend Gedanken darüber gemacht haben, dass die Funktion "Als Systemverwalter öffnen" sicher und stabil ist.

Newubunti schrieb:

sudo -H nano DATEI 

Für Nano braucht man doch die Option -H nicht. Warum führst Du gerade das als Beispiel an?

Da würde ich als Leser denken: "Ihr habt doch nicht mehr alle Latten am Zaun!"

👍

Und um das festzuhalten: Ich bin dafür, mit Rootrechten so sparsam wie möglich umzugehen!!!

Richtig!
Und wenn es doch notwendig ist, sollte auf einem modernen GUI-System dafür auch ein dem würdiger komfortabler Weg angeboten werden. sudo nano gehört für mich eindeutig nicht dazu und gedit admin:///... oder VISUAL=gedit sudoedit /... nur sehr bedingt.

Und allem anderen, was Du schreibst, stimme ich im wesentlichen zu.

Hallo,

Und Du gehst davon aus, dass Nemo dann nicht zu den "meisten Programmen" gehören wird?

Nach deiner Beschreibung läuft das bei Nemo über Polkit. Dazu wurde ja auch schon was gesagt.

Außerdem: du kannst gerne noch 100x mal "Nemo" sagen - aber in dem Artikel "mit Root-Rechte arbeiten" geht es nicht um den Mikrokosmos des Editors $FOO, sondern um's größere, ganze.

Hier schon wieder das Sicherheitsargument, warum? Wenn ich mit sudo nano oder sudo mv (siehe oben) einen Fehler mache, habe ich als Resultat doch dasselbe "Sicherheitsproblem".

Du verstehst den Kontext immer noch nicht... Es geht nicht darum _was_ man macht (aka: ggf. einen Fehler) sondern _wie_. Du kannst dir auch ohne Root-Rechte alle Dateien im Homeverzeichnis löschen, was in der Regel ein Fehler ist. Oder wenn du dir alle Dateien in /etc löschst ist es auch ziemlich egal, ob du das mit sudo nautilus oder sudo rangeroder sudo rm... gemacht hast. Es geht darum welches Programm inkl. zugehörigem Unterbau mit erhöhten Rechten läuft.

Gruß, noisefloor

kB schrieb:

1. und das Programm Nemo mit dieser tollen Option, der Du vertraust, gibt es gar nicht auf allen Desktops

Wüsste nicht, wo man Nemo nicht nachinstallieren kann, ist doch im normalen Ubuntu-Repo.

und Standard ist es wohl nur beim Derivat Budgie.

Du hast da noch das mittlerweile offizielle Derivat Ubuntu Unity übersehen, wo Nemo auch Standard ist.

Dein Privatweg ist nicht Wiki-tauglich.

Dann sind aber viele Artikel-Inhalte nicht Wiki-tauglich, wie z.B. die von AudioPlayer, Multimedia, Grafik. Auch da werden zahlreiche Programme und deren Möglichkeiten angeführt, die nicht zum Standard gehören.

noisefloor schrieb:

Und Du gehst davon aus, dass Nemo dann nicht zu den "meisten Programmen" gehören wird?

Nach deiner Beschreibung läuft das bei Nemo über Polkit. Dazu wurde ja auch schon was gesagt.

Also macht Nemo es doch richtig, oder?

Es geht darum welches Programm inkl. zugehörigem Unterbau mit erhöhten Rechten läuft.

Und dazu gehört IMHO eben auch Nemo, zum 101-ten Mal 😉

UlfZibis schrieb:

Wenn ich mich nicht ganz schlimm irre, führt das aber zu falschen Besitzverhältnissen und Rechten für die Datei /etc/fstab.

Deswegen schrieb ich ähnlich. Du kannst aber --preserver-Schalter verwenden oder noch ein chmod reinnehmen. Es geht nur darum, das sudoedit mit einer temporären Datei arbeitet und lediglich nach der Bearbeitung das per GUI fertig bearbeitete Produkt mit Rootrechten wieder an seinen Platz zaubert. Und genau so ist der Weg schon immer gedacht. So wenig Rechte wie möglich / so viel wie nötig. Das war auch noch nie anders, nur erwartet der Nutzer mittlerweile, das die Software das Denken übernimmt.

Und in einem Artikel der da heißt "mit Root-Rechten arbeiten" sollten IMHO alle möglichen Wege zusammengefasst aufgezählt werden (mit entsprechenden Hinweisen bzgl. Risiko etc.).

Warum? Es sollten die unter Ubuntu verwendeten Standards gelten, nicht alle möglichen Wege (das sind immens viele, nicht nur su, sudo, pkexec). Und Ubuntu setzt auf systemd, PolicyKit, … Natürlich kannst du rc.local verwenden und du kannst auch sudo nautilus machen oder cronjobs einrichten, eine grafische Umgebung komplett als root starten,… Nur hat das mit Ubuntu nix zu tun. Das Wiki hier sollte sich auf Ubuntu konzentrieren und auf das, was für Anfänger mit dem geringst möglichen Wissen verwendbar ist, möglichst mit Standardpaketen. Da ist schon ausreichend Unterschied durch die diversen Geschmäcker vorhanden.

Wird das unterlassen, wird – vor allem der Einsteiger – "kreativ" und probiert so Sachen wie sudo nautilus. Was dann kommt, kennen wir ... Forumsanfragen wie: "Einstellungen in Nautilus werden nicht gespeichert". Ich muss zugeben, dass auch mir das anfangs passiert ist. Dann wurde zunächst gksudo empfohlen bis sich dann irgendwann sudo -H als einigermaßen komfortable und zumindest gangbare Weise herausstellte, ich den "Königsweg" mittels Nemo aber selbst entdecken musste.

Das ist aber auch alles hornalt und wird seit Jahren eben nicht mehr unterstützt, seit X11 nicht mehr als root läuft. Aber anstatt mal den Kopf einzuschalten und sich zu fragen, wieso die Entwickler sich so massiv Mühe geben das nach 30 Jahren doch zu ändern, sucht man halt lieber Wege, um jeglicher möglichen Schadsoftware die Türen offen zu halten. Prima. Übrigens auch ein Grund, wieso wir sowas wie Snap und Flatpak forciert serviert bekommen.

Danke dass Du das mal klärst. Umso weniger verstehe ich, warum in dieser Diskussion immer wieder mit dem (Totschlag-)Begriff "Sicherheit" argumentiert wird.

Vermutlich weil die meisten Rechner am Internet angebunden sind und wir vermeiden wollen noch mehr Kinderpornos zu verteilen. „Is mir egal, mir passiert ja nix, außer paar Euro mehr Stromkosten im Jahr“ sollte schon lange aus den Denkprozessen entfernt sein.

Ich habe mich auf die Stabilität beschränkt, die beeinträchtigt wird, da root keine grafische Umgebung hat und somit die des Nutzers übernimmt.

Wenn das generell zu einem solchen Problem führt, sollte das IMHO als Bug behandelt werden, und nicht als "Fehlbedienung" des Nutzers. Es ist nun mal offiziell so vorgesehen, dass wenn ich Programme wie Synaptic oder GParted aufrufe, ich zu anfangs nach dem Passwort gefragt werde, und ab da die graphische Anwendung dann unter root läuft.

Nö. Die läuft als dein Benutzer. Teile des Programms erhalten aber nach Eingabe des Passworts erweiterte Rechte, eben über DBus, nen daemon, je nachdem wie das implementiert ist. Das ist nicht vergleichbar mit dem Aufruf des grafischen Programms mit Rootrechten.

Und Du gehst davon aus, dass Nemo dann nicht zu den "meisten Programmen" gehören wird? Wo nimmst Du das her? (Seit 1972 heißt es schon, das Erdöl geht in 10 Jahren aus.)

Ich weiß nicht wie nemo funktioniert, da ich mir das nie angeguckt habe, würde aber stark vermuten, das da das PolicyKit verwendet wird. Musst du selbst mal nachgucken. Die hätten das dann schon umgesetzt. Und wie oben geschrieben, das ist was völlig anderes als das komplette Programm mit allen Unterprozessen als root zu starten, wie du das mit sudo tun würdest.

Dachte ich mir doch, dass das etwas komplizierter ist. Und bis dahin – also bis mir jemand das Gegenteil beweist – gehe ich davon aus, dass sich die Entwickler von Nemo ausreichend Gedanken darüber gemacht haben, dass die Funktion "Als Systemverwalter öffnen" sicher und stabil ist.

Dir muss keiner was beweisen. Du musst nur die Manpages lesen und wenn du etwas nicht glaubst Gegenbeweise bringen. Idealerweise schreibst du ein eigenes Programm mit GUI und testest verschiedene Szenarien. Und was nemo angeht, das kennt hier außer dir wohl keiner. Wir reden hier vom Umgang mit Rootrechten, nicht von Funktionen in nemo, krusader (der kann das auch) oder sonstigen Tools.

ChickenLipsRfun2eat schrieb:

Das ist aber auch alles hornalt und wird seit Jahren eben nicht mehr unterstützt, seit X11 nicht mehr als root läuft.

Ich beschrieb ja die Vergangenheit.
Es wird aber immer wieder neue Nutzer geben, die der Versuchung sudo nautilus unterliegen werden, weil sie all das hier Vorgeschlagene zu aufwendig, kompliziert oder was auch immer finden. Dem könnte man mit der Empfehlung, statt dessen Nemo und das richtig zu nutzen, entgegenwirken.

... sucht man halt lieber Wege, um jeglicher möglichen Schadsoftware die Türen offen zu halten. Prima. Übrigens auch ein Grund, wieso wir sowas wie Snap und Flatpak forciert serviert bekommen.

Zustimmung.

Nö. Die läuft als dein Benutzer. Teile des Programms erhalten aber nach Eingabe des Passworts erweiterte Rechte, eben über DBus, nen daemon, je nachdem wie das implementiert ist.

Und welchen Grund hast Du zu der Annahme, dass Nemo das nicht auch so richtig macht?

Das ist nicht vergleichbar mit dem Aufruf des grafischen Programms mit Rootrechten.

Damit kann ich tatsächlich was anfangen. Deshalb betrachte ja auch ich sudo -H als Krücke, die gut gehen kann, aber nicht muss. Früher oder später wird der ein oder andere unbedarfte Einsteiger da aber doch mal (zumindest probehalber) "vorbeischauen".

Ich weiß nicht wie nemo funktioniert, da ich mir das nie angeguckt habe, würde aber stark vermuten, das da das PolicyKit verwendet wird. Musst du selbst mal nachgucken. Die hätten das dann schon umgesetzt.

Da habe ich volles Vertrauen, dass das so ist, denn bisher sprach ja nichts dagegen.

... wie du das mit sudo tun würdest.

Ich ja auch nirgendwo geschrieben habe, dass ich das tue.

Dir muss keiner was beweisen.

Außer der, der mich davon abbringen will, Nemo weiter so zu benutzen.

Und was nemo angeht, das kennt hier außer dir wohl keiner.

Und weil das zu meiner Überraschung so so ist, habe ich Nemo mal etwas in den Vordergrund gerückt. Ich dachte immer, das jeder, der mit Ubuntu ein bisschen mehr macht, als nur Surfen und Videos gucken, von dem "schlanken" Nautilus längst irgendwann auf Nemo oder anderes besseres umgestiegen sei.

UlfZibis schrieb:

Wüsste nicht, wo man Nemo nicht nachinstallieren kann, ist doch im normalen Ubuntu-Repo.

In dem Artikel geht es aber nicht um "welchen Dateimanager, den es erst ab 23.04 in einem offiziellen Ubuntu-Derivat vorinstalliert geben wird, kann ich überall nachinstallieren, wenn mir danach ist".

Zudem kann Nemo "lustige" Nebeneffekte haben, wenn es unter GNOME oder Unity (vermutlich auch unter Budgie) installiert wird.

tomtomtom schrieb:

In dem Artikel geht es aber nicht um "welchen Dateimanager,

... aber auch nicht ausschließlich um "mit Root-Rechten editieren", sondern um ARBEITEN, und da gehört für mich ein Dateimanager dazu, weiß ja nicht wie das bei Dir ist.

den es erst ab 23.04 in einem offiziellen Ubuntu-Derivat vorinstalliert geben wird,

Nee in Ubuntu-Unity schon seit immer und seit 22.10 als offizielles Derivat, und wie es bei Budgie ist, weiß ich nicht.
Und wer schreibt vor, dass man in diesem Zusammenhang nur Vorinstalliertes verwenden darf?

Zudem kann Nemo "lustige" Nebeneffekte haben, wenn es unter GNOME oder Unity (vermutlich auch unter Budgie) installiert wird.

Erzähl' doch mal bitte ...

Hallo,

aber das Wiki schreibt keine Programme vor (wie einen Editor oder Dateimanager), wenn nicht ein zwingender Grund dafür besteht, Programm $FOO zu nehmen.

Bei diesen übergreifenden Artikel muss man halt dazu in der Lage sein, seine eigenen Mikrokosmos zu verlassen und globaler / übergreifender zu denken. Kann nicht jeder, ist auch nicht weiter schlimm. Nur sollte man halt auch bei so Artikel besser die Füße still halten.

Gruß, noisefloor

UlfZibis schrieb:

Nee in Ubuntu-Unity schon seit immer und seit 22.10 als offizielles Derivat, und wie es bei Budgie ist, weiß ich nicht.

Ubuntu-Unity gibt es erst seit 22.10...

Das man da jetzt zum Unity jede Menge Software, die damit nichts zu tun hat (halbes MATE und Nemo aus Cinnamon, aber nautilus-data und nautilus-extension-gnome-terminal) mitliefert - ich sag da mal lieber nichts zu. 😈

Und wer schreibt vor, dass man in diesem Zusammenhang nur Vorinstalliertes verwenden darf?

Das hier ist ein Grundlagenartikel. Der sollte sich mit der vorinstallierten Software befassen und nicht "installiere xy nach, um das nachvollziehen zu können".

Erzähl' doch mal bitte ...

Nemo kann den Desktop verwalten und so Funktionen von Nautilus oder Caja übernehmen, was dann zu irritationen führt, wenn deren Einstellungen nicht mehr funktionieren, weil in dconf auf einmal Nemo eingetragen ist...

UlfZibis schrieb:

Newubunti schrieb:

sudo -H nano DATEI 

Für Nano braucht man doch die Option -H nicht. Warum führst Du gerade das als Beispiel an?

Das steht derzeit so als Beispiel im Artikel.

LG, Newubunti

noisefloor schrieb:

aber das Wiki schreibt keine Programme vor (wie einen Editor oder Dateimanager),

Aber eins nicht zuzulassen ist doch dasselbe.

Bei diesen übergreifenden Artikel muss man halt dazu in der Lage sein, seine eigenen Mikrokosmos zu verlassen und globaler / übergreifender zu denken.

Ja genau, mal über den Tellerrand schauen und z.B. Nemo erwägen.

tomtomtom schrieb:

Ubuntu-Unity gibt es erst seit 22.10...

Nein, seit 20.04. Und oh, aus 23.04 wurde schon mal 22.10.

Das man da jetzt zum Unity jede Menge Software, die damit nichts zu tun hat (halbes MATE und Nemo aus Cinnamon, aber nautilus-data und nautilus-extension-gnome-terminal) mitliefert - ich sag da mal lieber nichts zu. 😈

Es gibt sicher noch was zu tun.

Nemo kann den Desktop verwalten und so Funktionen von Nautilus oder Caja übernehmen, was dann zu irritationen führt, wenn deren Einstellungen nicht mehr funktionieren, weil in dconf auf einmal Nemo eingetragen ist...

Ja wenn beides installiert ist, muss man sich darum kümmern. Wie das geht ist unter Nemo schon seit langem beschrieben. In Ubuntu-Unity ist allerdings nur Nemo vorinstalliert.

Newubunti schrieb:

UlfZibis schrieb:

Für Nano braucht man doch die Option -H nicht. Warum führst Du gerade das als Beispiel an?

Das steht derzeit so als Beispiel im Artikel.

Wer das wohl mal so verbrochen hat?