staging.inyokaproject.org

Hallo,

Da viele Nutzer unbedarft sind, wäre vielleicht ein „tl;dr“ noch gut, um auch die lesefaulen Nutzer abzuholen.

+1. Dieser Artikel wird ja super oft im Wissensblock verlinkt. Die IMHO häufigste Verlinkung ist im Kontext mit einem Editor, also so wie "Dann öffnet man die Datei $FOO mit einem Editor mit Root-Rechten^[3][4] und fügt die Zeile...".

Das Thema Editor taucht zwar im Artikel auf, aber eher am Rande und nicht als Punkt im Inhaltsverzeichnis. Das sollte IMHO unbedingt geändert werden, damit der Artikel den Sinn noch erfüllt, weswegen er ursprünglich überhaupt angelegt wurde und weswegen er dann im Wissensblock verlinkt wird, anstatt wie vor Existenz des Artikel sudo zu verlinken.

Gruß, noisefloor

noisefloor schrieb:

… Die IMHO häufigste Verlinkung ist im Kontext mit einem Editor, also so wie "Dann öffnet man die Datei $FOO mit einem Editor mit Root-Rechten^[3][4] und fügt die Zeile...".

Das sollte auf sudoedit verlinken, wenn das einfach möglich ist. Dürfte die einfachste und gangbarste Methode sein, diese gilt dann aber nicht für .

kB schrieb:

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

Ubuntu Budgie verwendet nicht Caja, sondern Nemo als Standard-Dateimanager, oder hier steht was falsches.
Also "Budgie" im Abschnitt Caja entfernen und im Abschnitt Nemo einfügen.

Bei der Verwendung dieser Menüpunkte wird immer ein Programm unter dem Benutzer root gestartet, entweder Nemo selbst, oder ein Editor wie Pluma oder ein anderes Programm.

Wie soll denn in einem System wie Ubuntu MATE per Caja-Kontextmenü da Nemo aufgerufen werden, wenn Nemo da gar nicht zum System gehört?

Hier fehlt ein Doppelpunkt: "[:Nautilus#Mit-Root-Rechten-arbeiten]"

Bei Thunar könnte man noch die "Custom Action" – mit entsprechenden Warnhinweisen – erwähnen, siehe 9372388

+1 Ein insgesamt sehr gut ausgearbeiteter Artikel.

noisefloor schrieb:

Das Thema Editor taucht zwar im Artikel auf, aber eher am Rande und nicht als Punkt im Inhaltsverzeichnis. Das sollte IMHO unbedingt geändert werden, damit der Artikel den Sinn noch erfüllt, weswegen er ursprünglich überhaupt angelegt wurde ...

+1

Hallo,

also an sich ist das ja eine ausführliche Abhandlung, was ich grundsätzlich immer begrüße, aber wer als Normalanwender diese fette Warnbox liest, der springt doch danach aus dem Fenster. Ich verstehe auch, dass das ein komplexes Thema ist und es damit leichter gesagt, als aus Autorensicht schriftlich getan, ist, dass dann praktisch umzusetzen und in einen Artikel zu gießen. Weiterhin verstehe ich auch, dass der Artikel jetzt eigentlich das behandelt, was auch der Titel sagt, nämlich "mit Root-Rechten arbeiten". Am Titel orientiert, ist der Artikel-Inhalt daher jetzt passender, als vorher.

ABER:

Aus Sicht eines Normalanwenders ist mir das zu komplex und es fehlt mir hier die Leserführung, wie ich mittels GUI auf sicherstem Weg mal eben eine Einstellung in Datei XY ändere.

Ich finde es aus dieser Perspektive didaktisch nicht sinnvoll, dass die Root-Shell soweit oben platziert ist, wenngleich ich zugebe, dass dies das vom Artikel-Titel her eigentlich am treffendsten ist.

Denn z.B. bei sudoedit arbeite ich ja gar nicht mir Root-Rechten, sondern ich speichere nur mit Root-Rechten.

Ich finde den Artikel an sich gut, aber er geht IMO hier an den Publikumsinteressen zu weit vorbei bzw. überfordert der Artikel so denjenigen, der mal eben auf sichere Weise nur eine kleine Einstellung mit (grafischem) Editor ändern will - was IMO immer noch der in der Praxis häufigste Anwendungsfall sein dürfte.

Wenn der Artikel nicht schon mehrfach verlinkt wäre, würde ich empfehlen, einen zusätzlichen vereinfachten Artikel zu erstellen.

Eigentlich geht es dem Leser thematisch ja um "Editieren von Systemdateien". Da gibt es Schnittmengen mit diesem Artikel, aber es ist nicht exakt das gleiche, wie "mit Root-Rechten arbeiten".

LG, Newubunti

• Wäre nicht der Zugang über chroot noch als eine 9. Methode zu erwähnen?

• Die Erklärungen für A1 ... A5 sollten IMHO direkt unter der Tabelle, wo sie verwendet werden, zu finden sein.

• Nur bei unkritischen Systemen darf man auch per GUI als Root arbeiten. Diese Einschränkung ist weniger einschränkend als man zunächst glaubt, denn bei als kritisch eingestuften Systemen darf vernünftigerweise überhaupt keine GUI installiert sein.

Das finde ich eine sehr wichtige Erklärung, die man leider nur per Zufall findet. Deshalb sollte IMHO an prominenter Stelle mal genau erklärt werden, was ein "kritisches System" ist und was auf unkritischen Systemen durchaus tolerabel ist, wie z.B. sudo -H GUI oder Kontextmenü → "Als Systemverwalter ...", bzw. welche "Gefahr" sich daraus tatsächlich ergibt. In diesem Sinne ist ein gewöhnliches alleinstehendes "Zuhause-Desktop-System" IMHO als unkritisch einzustufen. Linux Mint und Ubuntu-Unity z.B. vertrauen wohl voll darauf und bieten deshalb auch standardmäßig solche Administrator-Zugänge z.B. per Nemo an.

Newubunti schrieb:

Aus Sicht eines Normalanwenders ist mir das zu komplex und es fehlt mir hier die Leserführung, wie ich mittels GUI auf sicherstem Weg mal eben eine Einstellung in Datei XY ändere.

+1

Denn z.B. bei sudoedit arbeite ich ja gar nicht mir Root-Rechten, sondern ich speichere nur mit Root-Rechten.

Genau ... eine wichtige Unterscheidung.

Eigentlich geht es dem Leser thematisch ja um "Editieren von Systemdateien".

+1

Vielleicht folgende Aufteilung:

1. Einführende Erklärung, was ein "kritisches System" etc. ist und genaue Erklärung der tatsächlichen Gefahren.

2. Für den Normal-User einfache Anleitung unter Berücksichtigung "kritisches / unkritisches System" für den üblichen Fall: "Editieren / Anlegen / Kopieren / Verschieben von Systemdateien".

3. Detaillierte Abhandlung, so ähnlich wie jetzt vorhanden.

UlfZibis schrieb:

… standardmäßig solche Administrator-Zugänge z.B. per Nemo an.

Und sagen hinterher rtfm 😉 Das Problem bei diesem Zugang ist ja, das Dateien öffnen dann auch mit Rootrechten funktioniert und somit weitere Programme als solche zu starten versucht werden. Einige Probleme, wie bspw. das enteignen vom klassischen ~/.Xauthority umgeht man, aber du kannst nicht für jede verknüpfte Software erwarten, das sie mit Rootrechten klarkommt. Wenn du eine gewisse Kombination testen willst, tu das — aber erwarte keine pauschale Aussage. Das unterscheidet sich immens von „lässt sich nicht starten / coredumps“ über „schrottet systemweite Dateien“ bis hin zu „funktioniert problemlos“.

… Erklärung, was ein "kritisches System"

Auch da gibt es keine pauschale Antwort. Wenn das System vor die Hunde geht und alle Daten vernichtet sind, ist das dann schlimm für dich? Dann ist es ein kritisches System. Wenn dir Internetsicherheit, Datenintegrität, etc. egal sein können, dann nicht — bspw. in einer offline-VM zum rumbasteln. Wenn die vor die Hunde geht, stellst du einfach nen snapshot wieder her und versuchst es nochmal.

"Zuhause-Desktop-System" IMHO als unkritisch einzustufen

Das ist meistens mit dem Internet verbunden, also kritisch. Du trägst Verantwortung dafür was mit anderen passiert, die durch deine Fahrlässigkeit (Surfen mit veraltetem Browser, etc.) geschädigt werden können (Botnetze & Co).

UlfZibis schrieb:

• Nur bei unkritischen Systemen darf man auch per GUI als Root arbeiten. Diese Einschränkung ist weniger einschränkend als man zunächst glaubt, denn bei als kritisch eingestuften Systemen darf vernünftigerweise überhaupt keine GUI installiert sein.

Das finde ich eine sehr wichtige Erklärung,

Die IMO aber so pauschal gar nicht getroffen werden kann und auch nicht getroffen werden sollte.

Ein System mit dem ich per Browser Online-Banking verwende, ist für mich aus der Perspektive eines Normalanwenders ein kritisches System. Laut Aussage, darf auf diesem vernünftigerweise gar keine GUI installiert sein.

Das ist eine daher sehr wenig hilfreiche und IMO in der Form falsche Aussage.

LG, Newubunti

Newubunti schrieb:

UlfZibis schrieb:

• Nur bei unkritischen Systemen darf man auch per GUI als Root arbeiten. Diese Einschränkung ist weniger einschränkend als man zunächst glaubt, denn bei als kritisch eingestuften Systemen darf vernünftigerweise überhaupt keine GUI installiert sein.

Das finde ich eine sehr wichtige Erklärung,

Die IMO aber so pauschal gar nicht getroffen werden kann und auch nicht getroffen werden sollte.

Eben, sie sollte nicht pauschal sein, sondern die einzelnen tatsächlichen Gefahren einigermaßen nachvollziehbar erklären, und bei welcher Methode sie zum Tragen kommen. Der oben zitierte Punkt aus dem aktuellen Wiki-Text ist aber gerade sehr pauschal, seiner Wichtigkeit nach schlecht platziert und wenig erklärend.

Ein System mit dem ich per Browser Online-Banking verwende, ist für mich aus der Perspektive eines Normalanwenders ein kritisches System. Laut Aussage, darf auf diesem vernünftigerweise gar keine GUI installiert sein.

Das ist eine daher sehr wenig hilfreiche und IMO in der Form falsche Aussage.

Bingo, eben völlig an der Realität vorbei. Und Millionen Nutzer von Linux-Mint werden deshalb auch nicht auf Ubuntu unter GNOME umsteigen, weil man da zur "Sicherheit" mehr oder weniger gezwungen wird. Sie leben offensichtlich ziemlich gut mit den "Gefahren" von Linux-Mint.

Und man ist ja auch nicht gleichzeitig per Browser im Online-Banking unterwegs, während man Systemdateien bearbeitet.

Newubunti schrieb:

Ein System mit dem ich per Browser Online-Banking verwende, ist für mich aus der Perspektive eines Normalanwenders ein kritisches System. Laut Aussage, darf auf diesem vernünftigerweise gar keine GUI installiert sein.

Geht auch ohne GUI 😉

Aber hier muss man mal die Kirche im Dorf lassen. Es geht ums Arbeiten mit Rootrechten. In diesem Zusammenhang sind kritische Systeme diejenigen, die zum einschränkungsfreien Weiterleben nötig sind. Dein Router, Datenserver, lokales Netzwerk, kritisch wichtige Dokumentablagen, etc. Onlinebanking gehört da nicht direkt dazu.

Im Zusammenhang des Artikels sollte das auch klar werden — es geht darum nicht mit GUI Zugriff auf die „Eingeweide“ des Systems zu haben. Eine abgeschottete GUI stellt nur für deren Zugriffsbereich eine Gefahr dar — und insofern habt ihr auch wieder Recht, weil unter Ubuntu durch die Standard-Allround-Zugriffsklausel in sudo der Hauptbenutzer sowohl eine GUI hat, als auch in den Eingeweiden rumoperieren darf. (Ich persönlich halte das für völlig falsch, aber das kam wohl aus der Windows- oder Macwelt rübergeschwappt).

Hallo,

also aus rein pragmatischer Wikisicht ist IMHO der (vermutlich mit Abstand) häufigsten Anwendungsfall, dass man ein Konfigdatei für Programm oder Dienst $FOO unterhalb von /etc editieren will (oder muss).

Also ich finde den Artikel an sich auch gut - aber nicht für den ursprünglichen Ausgangspunkt. Stimme mit dem, was Newubunti dazu geschrieben hat, ziemlich überein.

Gruß, noisefloor

noisefloor schrieb:

Also ich finde den Artikel an sich auch gut - aber nicht für den ursprünglichen Ausgangspunkt.

Das möchte ich auch noch mal unterstreichen: Der Artikel ist didaktisch durchdacht und gut!

Ich finde die eine oder andere Warnung übertrieben, aber man sieht schon, dass da Mühe und ein Konzept in den Artikel gesteckt wurde und der Artikel hält sich auch sehr schön am Artikeltitel.

Der Mangel ergibt sich hier mehr aus der Artikel-Historie und dem dahinter eigentlich steckenden Zweck, der damals möglicherweise und aus heutiger Sicht mit hoher Sicherheit mit einem nicht so günstigen Titel bedacht wurde.

Das ist mal einer der Momente, wo es mir schwer fällt, etwas konstruktives zur Auflösung dieses Dilemmas beizusteuern.

Wenn man die Artikel-Historie und den ursprünglichen Zweck des Artikels betrachtet, dann wäre es vielleicht am einfachsten aufzulösen, wenn man diesem neuen Artikel einen anderen Titel gibt - der dann aber weniger gut zum Inhalt passen wird.

An diesem Artikel grundsätzlich groß rumschrauben fände ich eigentlich schade, weil der in sich schon stimmig ist.

LG, Newubunti

ChickenLipsRfun2eat schrieb:

Dein Router, Datenserver, lokales Netzwerk, kritisch wichtige Dokumentablagen, etc. Onlinebanking gehört da nicht direkt dazu.

Das ist doch eine völlig willkürliche Aufzählung bzw. ein völlig willkürlicher Ausschluss des Onlinebankings. Warum soll Onlinebanking da nicht dazu zählen? Oder mal anders herum gefragt. Auf Deinem Router zuhause läuft Ubuntu-(Server)? Oder wieder anders herum gefragt, ein System auf dem man Onlinebanking betreibt, muss bzw. sollte nicht besonders geschützt werden?

Und ich weiß auch nicht, was es bringen soll - zumindest nicht im Rahmen der ubuntuusers.de-Plattform - das Arbeiten mit Root-Rechten vom Rest des Systems zu abstrahieren. Wenn ich Ubuntu-Desktop nutze, dann ist da halt nun mal eine GUI dabei. Laut Aussage des Artikels sind das automatisch alles keine "kritischen Systeme". Das kann doch so pauschal nicht richtig sein.

Für das Arbeiten mit Root-Rechten gibt es Anlässe und zwar unabhängig davon, ob es sich um ein "kritisches System" (was immer das im Rahmen der Plattform hier genau sein soll) handelt oder nicht bzw. unabhängig davon ob es eine GUI gibt oder nicht. Je besser ein System sicherheitstechnisch durchdacht und praktisch umgesetzt ist, um so weniger Anlässe zur Arbeit mit Root-Rechten sollte es IMO bieten.

Das sind wir aber bei Ubuntu bei der grundsätzlich falschen Distribution, weil deren Primärziel eine hohe Endanwender-Akzeptanz sowie -Nutzbarkeit und nicht höchst mögliche Sicherheit ist.

Und Linux an sich steht auch noch nicht automatisch für besonders hohe Sicherheit, sondern nach meinem Empfinden steht da häufig die Freiheit noch über der Sicherheit - gerade auch bei Linux-Desktop-Umgebungen.

Natürlich gibt Linux überhaupt erst die Möglichkeit verifizierbar, sichere Systeme zu konzipieren, d.h. aber nicht, dass dieses Ziel automatisch optimale Umsetzung findet.

Ich bleibe dabei, dass die Formulierung im Artikel mindestens wenig hilfreich ist, weil der Begriff "kritisches System" ein völlig unbestimmter Begriff ist. Auch beim Warnen sollte man die Kirche mal im Dorf lassen.

Diese Kritik soll aber die Anerkennung für einen sonst gut gelungen Artikel nicht schmälern!

LG, Newubunti

Newubunti schrieb:

ChickenLipsRfun2eat schrieb:

Dein Router, Datenserver, lokales Netzwerk, kritisch wichtige Dokumentablagen, etc. Onlinebanking gehört da nicht direkt dazu.

Das ist doch eine völlig willkürliche Aufzählung bzw. ein völlig willkürlicher Ausschluss des Onlinebankings.

Nein. Meine Beispiele beziehen sich auf systemweite Dienste. Onlinebanking ist was für einen einzelnen Benutzer. Das ist auch ohne Rootrechte gefährdet, da du als Benutzer ja in deinem Homeverzeichnis eh Vollzugriff hast ohne erst erweiterte Rechte zu erlangen. Das lässt sich ganz ohne Rootrechte ganz einfach beeinflussen. Bspw. lokal installierte Scripte, Browsererweiterungen, etc.

Auf Deinem Router zuhause läuft Ubuntu-(Server)? Oder wieder anders herum gefragt, ein System auf dem man Onlinebanking betreibt, muss bzw. sollte nicht besonders geschützt werden?

Nein, bei mir läuft gar kein Ubuntu. Ansonsten siehe oben.

Und ich weiß auch nicht, was es bringen soll - zumindest nicht im Rahmen der ubuntuusers.de-Plattform - das Arbeiten mit Root-Rechten vom Rest des Systems zu abstrahieren. Wenn ich Ubuntu-Desktop nutze, dann ist da halt nun mal eine GUI dabei. Laut Aussage des Artikels sind das automatisch alles keine "kritischen Systeme". Das kann doch so pauschal nicht richtig sein.

Ubuntu hat nicht immer eine GUI dabei. Sehr viele Installationen sind auch Serverinstallationen ohne GUI, die bspw. bei Hostern in Containern installiert werden. Die müssen auch mit Rootrechten, Benutzern und Gruppen, etc. umgehen und sind durch die permanente Anbindung ans Netz immer kritische Systeme.

Für das Arbeiten mit Root-Rechten gibt es Anlässe und zwar unabhängig davon, ob es sich um ein "kritisches System" (was immer das im Rahmen der Plattform hier genau sein soll) handelt oder nicht bzw. unabhängig davon ob es eine GUI gibt oder nicht. Je besser ein System sicherheitstechnisch durchdacht und praktisch umgesetzt ist, um so weniger Anlässe zur Arbeit mit Root-Rechten sollte es IMO bieten.

Deswegen existieren ja so viele Möglichkeiten sowas einzurichten, allen voran das Policy Kit (wobei ich da nicht genau weiß was der Debian-Fork anders macht als das Upstream-Projekt). Und diese Möglichkeiten werden hier aufgezeigt, damit sich jeder das für ihn passende (Server, Ubuntu, Flavours) raussuchen kann.

Das sind wir aber bei Ubuntu bei der grundsätzlich falschen Distribution, weil deren Primärziel eine hohe Endanwender-Akzeptanz sowie -Nutzbarkeit und nicht höchst mögliche Sicherheit ist.

Ich bin mir nicht sicher, ob Canonical dir da zustimmen würde 😉

Und Linux an sich steht auch noch nicht automatisch für besonders hohe Sicherheit, sondern nach meinem Empfinden steht da häufig die Freiheit noch über der Sicherheit - gerade auch bei Linux-Desktop-Umgebungen.

Freiheit ist Sicherheit. Nur wenn du etwas frei ändern kannst, kannst du dir sicher sein was genau passiert, in welcher Situation dein Regelwerk kippt, wo die Grenzen sind, etc. Bei unfreier Software bist du ganz auf die Angaben der Hersteller angewiesen, was wie wir alle wissen in vielen Daten-Katastrophen endet. Aktuelles Beispiel wäre MSI (wobei das eher unter „sehr dumm“ als unter „Softwareproblem“ läuft). Freiheit bedeutet aber auch nicht automatische Sicherheit, du hast lediglich die Kontrolle und Verantwortung darüber und verschiedene Wege deine Ziele zu erreichen.

Ich bleibe dabei, dass die Formulierung im Artikel mindestens wenig hilfreich ist, weil der Begriff "kritisches System" ein völlig unbestimmter Begriff ist. Auch beim Warnen sollte man die Kirche mal im Dorf lassen.

Dann schau mal wie viele Server verbastelt im Netz rumschwirren und wie mächtig heutige Botnetze sind.

Wie ich schon weiter oben schrieb: Für diejenigen, die nur eine Datei bearbeiten wollen/müssen kann ein Link auf sudoedit ausreichen. Der Artikel selbst heisst aber „mit Rootrechten arbeiten“ und nicht „HowTo: Einzelne Datei mit erweiterten Rechten bearbeiten“. Ich finde den daher weder zu lang oder inhaltlich falsch, irreführend, etc.

ChickenLipsRfun2eat schrieb:

[…] Link korrigieren zu [:mount:umount]

erl.

[…] [:D-Bus:] verlinken

erl.

[…] Verlinken mit [:Terminal#Virtuelle_Konsole:]

erl.

Home-Verzeichnis zerschossen

Link auf [:Homeverzeichnis#Rechte:]

Baue ich noch ein. Ich will aber zuerst die Schreibweise auf die mir nicht zusagende, aber Wiki-gängige Version Homeverzeichnis anpassen. Das mache ich offline.

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

Warum?

Bequemer: Man spart eine Benutzeranmeldung.
Weniger sicher: Angreifer kennen nun einen zulässigen Benutzernamen root. Dieser Benutzer kann natürlich wie jeder andere Benutzer gehackt werden.

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

Natürlich besser.

Neuere Versionen von Kubuntu ab 18.04 sind …

Der Teil kann raus. […]

erl.

Klasse geschrieben und schön ausführlich und umfangreich!

Danke.

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.

Ich denke, solche Unterschiede müssen nicht deutlicher in diesem Artikel behandelt werden und wären ggf. in den weiterführenden Artikeln besser aufgehoben.

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.

Ja. Konkrete Vorschläge wie dieser sind willkommen.

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

Ich habe so etwas mal als Keim angelegt. Direkt als zweiten Absatz gibt es nun einen Link auf einen weiteren Abschnitt „Systemdateien mit Editor bearbeiten“. Den fülle ich aber offline mit Inhalt.