[[Vorlage(Getestet, general)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] }}} [[Inhaltsverzeichnis()]] „Mit Root-Rechten arbeiten“ bedeutet, dass man mit vollen administrativen Rechten auf dem System arbeitet. Wer mit Root-Rechten bzw. in der Rolle [:Root:] arbeitet kann alle Dateien öffnen und lesen, [:Rechte:Datei- und Verzeichnisrechte] ändern, Systemdateien anlegen, ändern und löschen und vieles mehr; der Benutzer `root` ist allmächtig, was das jeweilige Rechnersystem anbetrifft. Oft benötigt man zur Bearbeitung einer Systemdatei die Fähigkeiten von `root`; wie man dabei praktisch vorgehen kann, ist im Abschnitt [#Systemdatei-mit-Editor-bearbeiten Systemdatei mit Editor bearbeiten] beschrieben. Weitere typische Anwendungsfälle zum Arbeiten mit Root-Rechten sind beispielsweise: * Ein defektes oder inkonsistentes Dateisystem reparieren. * Software systemweit installieren, z.B als Pakete aus [:Paketquellen:] oder mit anderen Methoden wie [:snap:], [:flatpak:] oder Kompilation aus Quelltexten. * Systemdateien erstellen öder ändern, z.B. für die [:Benutzer und Gruppen:Benutzerverwaltung], zur Konfiguration einer Systemkomponente oder eines [:Dienste:Systemdienstes]. * System von Schadsoftware oder sonstiger unerwünschter Software befreien. * [[Anker(Aufgabenklassen ) ]]Allgemein sind es fünf Aufgabenklassen, welche man in diesem Modus ausführen möchte: 1. (A1) Ein Programm mit anderen als den normalen Benutzerrechten starten. 1. (A2) Eine Datei bearbeiten, aus der man als normaler Benutzer nicht lesen bzw. in die man nicht schreiben kann, oder eine solche Datei erstellen oder löschen. 1. (A3) Die Metadaten einer Datei, insbesondere Besitzverhältnisse, Dateirechte oder erweiterte Attribute verändern. 1. (A4) Einen Ordner betreten, in welchen man als normaler Benutzer nicht wechseln kann. 1. (A5) Das Root-Dateisystem selbst offline bearbeiten (z.B. reparieren, sichern …). Standardmäßig arbeitet kein Benutzer unter Ubuntu und dessen Derivaten mit derart weitgehenden Rechten. Manche Benutzer gelten als [:Administrator:], d.h. sie verfügen damit über die Berechtigung, in die Rolle Root zu wechseln und damit die vollständige Verfügungsgewalt über das Rechnersystem zu erhalten. Bei Ubuntu ist ein Benutzer genau dann Administrator, wenn er Mitglied in der [:Benutzer und Gruppen:Gruppe] `sudo` ist. Die Gruppe der Administratoren und ob man selbst dazu gehört kann man einfach erfragen: [[Vorlage(Befehl, "getent group sudo" ) ]] Wenn man in dieser Liste den eigenen Benutzernamen nicht findet, braucht man in diesem Artikel nicht weiter zu lesen und sollte einen der Administratoren um Aufnahme in diesen illustren Kreis bitten, denn natürlich können die Administratoren (und nur diese) auch festlegen, wer Administrator ist und wer nicht. Falls es gar keinen Administrator gibt, siehe [#Problembehebung Problembehebung]. Umgekehrt kann es in manchen Fällen auch sinnvoll sein, wenn man selbst für eigene Aufgaben keine Root-Rechte benötigt, einen anderen Administrator zu bitten, einem diese Eigenschaft zu entziehen. Beispielsweise benötigt man für Online-Banking weder Root-Rechte noch die Fähigkeit, in die Rolle Root wechseln zu können; man kann daher für diese Aufgabe zur Erhöhung der eigenen Sicherheit einen Benutzer verwenden, der kein Administrator des Rechnersystems ist. Bei der Installation eines Ubuntu-Systems wird standardmäßig, ungefragt und automatisch der erste angelegte Nutzer des Systems ein Administrator, weitere Benutzer jedoch nicht automatisch. Zum tatsächlichen Wechsel in die Rolle Root gibt es verschiedene [#Methoden Methoden (M1 … M8)], von denen je nach [#Aufgabenklassen Aufgabenstellung (A1 … A5)], Situation und persönlichen Vorlieben die eine oder andere zweckmäßiger ist. (Vgl. [#Tabelle-1 Tabelle 1]) = Gefahren und Vorsichtsmaßnahmen = {{{#!vorlage Warnung Beim Arbeiten in Rolle Root unterliegt man mehreren Klassen von Gefahren: 1. Alle Befehle sind nun sehr viel mächtiger als in der normalen Benutzerrolle und können daher ungewollt auch Schaden anrichten. Deshalb sollte man grundsätzlich Vorsichtsmaßnahmen ergreifen: * Bereithalten eines Rettungssystems, mit dem man bei einem zerschossenen System den Rechner booten und Dateisysteme wie auch die Boot-Infrastruktur reparieren kann. * Vor der Veränderung einer Systemdatei die ursprüngliche Datei in eine Kopie sichern. * Vor der Veränderung einer Datei sich auch deren Metadaten, insbesondere Besitzer und Dateiberechtigungen anschauen und merken. * Vor der Veränderung einer Datei ruhig durchatmen, das eigene Hirn einschalten, alle Leute, die einen bei der Arbeit nerven könnten aus dem Zimmer schicken, sich überhaupt durch nichts hetzen lassen, sondern ruhig und konzentriert arbeiten. Besonnen arbeiten, das beginnt damit, sich zu überlegen, was jetzt falsch laufen könnte. * Beim Eintippen des Befehls die Möglichkeiten der automatischen Vervollständigung nutzen. * Da bei unixartigen Betriebssystemen alles eine Datei ist, gilt vorstehende Liste natürlich bei allen Arbeiten in der Rolle Root. 1. Es können aus dem System vertrauliche Informationen an Unberechtigte abfließen oder unerwünschte Daten/Programme auf das System gelangen. Dies liegt daran, dass beim Öffnen einer Datei auf einem EDV-System der Dateiinhalt vollständig oder teilweise in Caches, Puffer, Arbeitsspeicher, temporäre Sicherheitskopien usw. gelangen und hieraus als Datenmüll beim Abspeichern anderer Dateien verbreitet werden kann. Vielleicht ist auch schon eine unerkannte Schadsoftware auf dem Rechner vorhanden, die zwar selbst keine vertraulichen Dateien öffnen kann, aber begierig darauf wartet, dass jemand in der Rolle Root das für sie tut. Industriespionage ist eine weit verbreitete Realität. Deshalb auf Rechnern, welche vertrauliche Daten speichern, wozu natürlich immer personenbezogene Daten gehören, oder auf Rechnern, welche direkt auf reale Hardware einwirken können, beispielsweise in Wasserwerken, Industrieanlagen, Krankenhäusern, am besten aber immer und auf jedem Rechner diese Vorsichtsmaßnahmen beachten: * Nur dann in der Rolle Root arbeiten, wenn es unbedingt erforderlich ist und das gewünschte Ergebnis anders nicht erreichbar wäre! * Erweiterte Rechte mittels der hier beschriebenen Verfahren sollten nur verwendet werden, wenn eine Aufgabe dies wirklich erfordert, die Programmausführung also zum Beispiel unter dem Benutzer `root` erfolgen muss. * 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 ([:mount#umount:umount]), und alle nicht benötigten, entfernbaren Datenträger entfernen. * Keine Datei öffnen, die nicht geöffnet werden muss. * Die Arbeitsumgebung für Root so gut wie irgend möglich von der Arbeitsumgebung anderer Benutzer isolieren. Dies betrifft auch Anzeigeserver wie [:Xserver:X11] und [:Wayland:], Kommunikationswege wie [:D-Bus:], sowie gemeinsam genutzte Dienste, Programme, Dateien und Ordner. 1. Die Methoden des Wechselns in die Rolle Root können Nebenwirkungen haben, die auf unvollständiger Isolation der Arbeitsumgebungen von `root` und dem normalen Benutzer beruhen. Hierdurch können nicht nur Dateiinhalte wie vorstehend beschrieben kompromittiert werden, sondern z.B. durch unerkannte Fehler in der benutzten Software können auch Schäden an den Datenbeständen entstehen. Gegenmaßnahmen: * Die Arbeitsumgebung für Root so gut wie irgend möglich von der Arbeitsumgebung anderer Benutzer isolieren. (Das wurde schon genannt, ist aber auch für diesen Gefahrenkomplex relevant.) * Immer die simpelste, am besten getestete, aus entwickelte und gut bekannte Software verwenden, welche für die Aufgabenerfüllung ausreicht. Das bedeutet in der Regel auf Desktop-Umgebungen, Werkzeuge mit grafischer Oberfläche und Programme mit großem Funktionsumfang zu verzichten, wenn man das Ergebnis auch mit Kommandozeilenbefehlen und hier insbesondere mit GNU-Programmen erreichen kann. Siehe auch: [#Links Warum kein GUI-Programm als `root` laufen sollte] Eine falsche Verwendung von Root-Rechten kann das System unbrauchbar machen oder schlimmere Folgen haben. }}} = Methoden = Es gibt für einen Administrator zur Aktivierung der Root-Rechte mehrere mögliche Methoden, die nicht alle in jeder Situation angemessen sind oder auch unverfügbar sein können. Im folgenden Text werden diese Methoden mit M1 bis M8 markiert. Sie berücksichtigen die genannten Gefahren im unterschiedlichen Maße und werden hier (näherungsweise) mit abnehmendem Grad ihrer Sicherheit vor unerwünschten Nebenwirkungen und zunehmendem Grad ihrer bequemen Benutzbarkeit gelistet. Der Administrator muss selber entscheiden, welche Methode unter Berücksichtigung von Wichtigkeit und Bedeutsamkeit des Systems (gemessen an Art der gespeicherten Daten, Art und Umfang möglicher Folgen für Daten, Menschen und Umwelt nach Fehlfunktion, wirtschaftlicher Schaden bei Ausfall usw.) und persönlichen Fähigkeiten für die konkret anstehende Aufgabe angemessen ist. [[Anker(Tabelle-1 ) ]] ||<-9: tableclass="zebra_start3" rowstyle=title>Tabelle 1: Methoden für Aufgabenklassen || ||Methode||<-5:>[#Aufgabenklassen Aufgabenklasse]||<|2:>Neben-[[BR]]wirkungen||<|2:>GUI||<|2>Bemerkung|| ||A1||<:>A2||<:>A3||<:>A4||<:>A5|| ||[#M1 M1]: Root-Shell – Offline ||<:>(nein)||ja||<:>ja ||<:>ja ||<:>ja ||<:>+ ||<:>nein ||(nein): Man kann zwar natürlich ein Programm als `root` starten, aber dieses Programm läuft ja nicht im zu wartenden System, sondern im Wartungswerkzeug mit anderer Umgebung.|| ||[#M2 M2]: Root-Shell im Single-User-Mode||<:>ja ||ja||<:>ja ||<:>ja ||<:>nein ||<:>+ ||<:>nein || ||[#M3 M3]: Root-Shell per Anmeldung ||<:>ja ||ja||<:>ja ||<:>ja ||<:>nein ||<:>++ ||<:>nein || ||[#M4 M4]: sudo ||<:>ja ||ja||<:>ja ||<:>ja ||<:>nein ||<:>++ ||<:>nein || ||[#M5 M5]: sudoedit ||<:>nein ||ja||<:>nein||<:>nein||<:>nein ||<:>+ ||<:>(ja) ||(ja): Man kann in einer Desktop-Umgebung im Terminal mit `sudoedit` einen grafischen Editor benutzen.|| ||[#M6 M6]: Policy Kit ||<:>(ja) ||ja||<:>ja ||<:>ja ||<:>nein ||<:>++ ||<:>ja ||(ja): Nicht jedes Programm kann mit `pkexec` gestartet werden.|| ||[#M7 M7]: GVFS-Protokoll admin:// ||<:>nein ||ja||<:>nein||<:>nein||<:>nein ||<:>++ ||<:>ja || ||[#M8 M8]: GUI-Werkzeuge ||<:>nein ||ja||<:>ja ||<:>ja ||<:>nein ||<:>+++++ ||<:>ja || * Beachte: Mehr Kreuze in der Spalte Nebenwirkungen kennzeichnen eine höhere Gefahr für unerwünschte Nebenwirkungen als bei Methoden mit weniger Kreuzen auch bei korrekter Anwendung der Methode. * Wenn man den Rechner neu starten darf, kann und will, dann sind M1 und M2 die zu bevorzugenden Methoden. * Wenn ein Neustart des Rechners nicht zulässig ist, verwende man bevorzugt die Methoden M3, M4 oder M5. * Wenn nur eine Textdatei zu bearbeiten ist, ist M5 – `sudoedit` – immer richtig: [#Systemdatei-mit-Editor-bearbeiten Systemdatei bearbeiten] * Zu M8: GUI-Werkzeuge haben zwangsläufig einen drastisch größeren Programmumfang als Programme für die Kommandozeile. Die direkte Verwendung eines GUI-Werkzeugs für Arbeiten als Root durch Start des Programms unter dem Benutzer `root` ist deshalb immer dann als unsicher abzulehnen, wenn andere Methoden mit kleinerem Programmumfang zum selben Ziel führen. Man kann aber in manchen Fällen z.B. einen grafischen Dateimanager als Hilfsmittel zur Navigation benutzen und die nur für eigentliche Aufgabe (z.B. Bearbeitung einer Systemdatei) die Methoden M4-M7 einsetzen. ## * 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. == Root-Shell == Wer für umfangreichere Arbeiten am System im Terminal[1] viele Befehle als [:root:] ausführen muss, kann direkt eine interaktive Shell für den Benutzer `root` starten. Dann braucht man nicht jedem Befehl [#M4 sudo] bzw. [#M6 pkexec] voranstellen. In einer Root-Shell kann man optional [:chroot:] verwenden. in manchen Fällen ist das aus funktionalen Gründen sinnvoll oder auch zur Verbesserung der Trennung zwischen Arbeitsumgebung und Arbeitsobjekt. [[Anker(M1) ]] === M1: Root-Shell – Offline === Man schaltet den Rechner aus und startet ihn neu in ein Wartungssystem. Dies kann ein weiteres, vom zu wartenden System unabhängiges, lokal parallel installiertes Betriebssystem oder ein per Boot vom Netzwerk oder ein per zugestecktem Datenträger (USB-Stick oder CD/DVD) temporär angeschlossenes Betriebssystem sein. Der Start von einem optischen Datenträger gewährleistet automatisch und auf einfachste Weise die z.B. bei der Jagd auf Schadsoftware unverzichtbare Forderung nach einem nicht beschreibbaren Dateisystem. Wenn man nicht bereits `root` ist, siehe [#M3 M3]. [[Anker(M2) ]] === M2: Root-Shell im Single-User-Mode === Ein Single-User-Mode wird auch Einzelbenutzermodus, Wartungsmodus, "recovery mode", Single-User-Modus genannt. Genau genommen gibt es davon mehrere zu unterscheiden, und man muss immer genau beschreiben, welchen man meint. (GRUB gerät auch in einen "recovery mode", wenn er keine Konfigurationsdatei findet; dieser wird aber in diesem Artikel nicht behandelt.) Die (es gibt zwei!) im Rahmen dieses Artikel relevanten Zustände erreicht man mit folgender Prozedur: 1. Man schaltet den Rechner aus. 1. Man startet den Rechner neu bis zum Bedieninterface der Bootmanagers, z.B. dem GRUB-Menü, und unterbricht einen ggf. ablaufenden Countdown für den automatischen Start eines Betriebssystems. 1. Man wählt im Menü das zu startende Betriebssystem aus, startet dieses aber nicht, sondern bearbeitetet dessen Menüeintrag. Bei GRUB geht das über die Taste [[Vorlage(Tasten, E ) ]]. 1. Hier gibt es nun zwei Varianten: * Variante 1: Man fügt der Kernel-Kommandozeile die Option `single` hinzu; das darf man auch mit `S` abkürzen. Bei manchen Bootmanagern wird solch ein Menüeintrag bereits fertig vorbereitet und im Menü angeboten. * Variante 2: Man fügt der Kernel-Kommandozeile zwei Optionen hinzu: `single init=/bin/bash` 1. Man startet den modifizierten Menüeintrag. Bei der ersten Variante wird der Kernel normal geladen und gestartet, die `ìnitrd.img` wird normal abgearbeitet und es wird auf das Init-System des Betriebssystems, bei Ubuntu also normalerweise [:systemd:] umgeschaltet. Dieses initialisiert nun aber das System nur teilweise und bietet schließlich dem Bediener an, per Tastendruck [[Vorlage(Tasten, Eingabe ) ]] in den Wartungsmodus zu wechseln. Wenn man das macht ist man bereits ohne Passwort-Eingabe (!) als `root` angemeldet, allmächtig und ungestört, denn andere Benutzer können sich noch gar nicht anmelden. Das normale Root-Dateisystem ist bereits als Root-Dateisystem online, aber möglicherweise noch schreibgeschützt; ebenso alle weiteren in der Datei [:fstab:] genannten Dateisysteme, sofern erreichbar. Man muss daher davon ausgehen, dass Schadsoftware (falls es solche im System gibt) ebenfalls bereits aktiv ist. WLAN funktioniert ganz sicher nicht, andere Netzwerkschnittstellen sind möglicherweise ebenfalls nicht konfiguriert. Man hat kein grafisches System, keine Desktop-Umgebung und sollte so etwas auch nicht starten, sondern die Möglichkeiten der Shell nutzen. Man erhält die Shell, welche für den Benutzer `root` definiert ist, standardmäßig bei Ubuntu ist das die [:Bash:]. Aus diesem Zustand heraus kann man später den normalen Startvorgang fortsetzen, indem man die Shell z.B. per [[Vorlage(Tasten, Strg+D ) ]] beendet. Bei der zweiten Variante wird der normale Startvorgang bereits früher unterbrochen, noch in der '''initrd.img'''. `systemd` oder etwas anderes außerhalb der '''initrd.img''' wurde noch nicht gestartet. Man darf deshalb hoffen, dass Schadsoftware auch noch nicht aktiv ist, aber ganz sicher kann man nicht sein. Wenn die Schadsoftware die zusätzlich Hürde einer Einnistung in der '''initrd.img''' genommen hat, kann sie bereits aktiv sein. Das normale Root-Dateisystem ist bereits, möglicherweise noch schreibgeschützt, als Root-Dateisystem online; aber weitere in der Datei [:fstab:] genannte Dateisysteme wurden noch nicht eingebunden. Man ist `root`. Diesen Zustand beendet man nach getaner Arbeit am besten mit [[Vorlage(Tasten, Strg+Alt+Entf ) ]], was zu einem erneuten Start führt. [[Anker(M3) ]] === M3: Root-Shell per Anmeldung === Man kann den Rechner ganz normal bis zum Anmeldedialog durchstarten lassen, das ist entweder eine grafische Anmeldung über einen Displaymanager (bei Ubuntu [:GDM:], bei Derivaten [:LightDM:] oder [:SDDM:]) oder ein simpler Prompt `login:`. Man kann sich bei Ubuntu nicht direkt als Benutzer `root` anmelden, weil dafür kein Passwort existiert. Es ist vorgesehen, sich zuerst als normaler Benutzer mit der Administrator-Eigenschaft anzumelden und dann in die Rolle Root zu wechseln. Dies kann sowohl an einem über die Tasten [[Vorlage(Tasten, Strg+Umschalt+F1 ) ]] bis [[Vorlage(Tasten, Strg+Umschalt+F6 ) ]] erreichbaren [:Terminal#Virtuelle-Konsole:virtuellen Terminal] (einige von diesen können aber schon durch Displaymanager und Desktops belegt sein) oder in einer Desktopumgebung in einem gestartetem grafischem Terminal[1] geschehen. Zum Wechsel in die Rolle Root gibt es mehrere Möglichkeiten: * Standardbefehl ist das Programm [#M4-sudo sudo]: [[Vorlage(Befehl, "sudo -i" ) ]] * Der bei anderen Linux-Distributionen ebenfalls mögliche Befehl [[Vorlage(Befehl, "su --login root" ) ]] funktioniert bei Ubuntu erst nachdem man für `root` ein Passwort vergeben hat; dann benötigt man aber den Umweg über die vorherige Anmeldung als normaler Benutzer nicht, sondern kann sich im virtuellen Terminal beim Prompt `login:` direkt als `root` anmelden. Das ist sowohl bequemer als auch weniger sicher. Den Befehl kann man noch abkürzen und den Benutzernamen `root` weglassen, da dies die Vorgabe ist. Diese Schreibweisen bewirken alle dasselbe: {{{#!vorlage Befehl su --login su -l su - }}} * Der ebenfalls mögliche Befehl [[Vorlage(Befehl, "pkexec bash -l" ) ]] ist eine Anwendung des Verfahrens per [#M6-Policy-Kit Policy Kit], bietet hier aber keine Vorteile gegenüber `sudo`. Er setzt zudem einen funktionierenden D-Bus voraus. Nach Beendigung der Arbeiten sollte man die Root-Shell unbedingt mit [[Vorlage(Befehl, "exit" ) ]] oder [[Vorlage(Tasten, Strg+D ) ]] verlassen, um in eine normale, unprivilegierte Shell zurück zu kehren. == sudo und sudoedit == Das Programm [:sudo:] ermöglicht nicht nur den [#M3-Root-Shell-per-Anmeldung Wechsel in eine interaktive Shell für root], sondern auch Ausführung von Programmen und Befehlen in einer nicht-interaktiven Shell als `root`. Der Befehl [:sudo/#Editieren-von-Dateien-unter-Sudo-Rechten-sudoedit:sudoedit] ist ein alternativer Name für das Programm `sudo`, welches sich aber beim Aufruf über den Namen `sudoedit` ganz anders verhält und dient zum Editieren von Dateien, deren Einsicht und Änderung normalen Benutzern verwehrt ist. [[Anker(M4) ]] === M4: sudo === Das Programm [:sudo:] ist „das Schweizer Taschenmesser für Administratoren“. Jeder Administrator muss dieses Programm gut kennen; insbesondere die Bedeutung seiner Optionen `-H` und `-i`. [:sudo:Wiki-Artikel] und [:Manpage:] gehören daher zur Pflichtlektüre verantwortungsbewusster Administratoren. Der Befehl `sudo` wird einfach dem als `root` auszuführenden Befehl BEFEHL vorangestellt: [[Vorlage(Befehl,"sudo OPTIONEN BEFEHL" ) ]] Dieser klassische Linux-Weg für Verwaltungsaufgaben ist technisch zwar mit jedem Programm/Befehl anwendbar, jedoch sollte man `sudo` bei Programmen mit grafischer Oberfläche vermeiden. Es ist bei dieser Methode immer davon auszugehen, dass die Arbeitsumgebungen von `root` und dem normalen Benutzer __nicht__ vollständig entkoppelt werden können; somit können unerwünschte Nebeneffekte wie z.B. verbogene Besitzverhältnisse oder Dateiberechtigungen auftreten. Bei jeder Anwendung dieser Methode sollte man über die für den aktuellen Aufruf sinnvollen Optionen (siehe [:sudo:]) nachdenken mit dem Ziel, die Arbeitsumgebungen von `root` und dem normalen Benutzer soweit wie möglich zu entkoppeln: * Beispielsweise ist die Option `-H` fast immer sinnvoll. Damit wird die [:Umgebungsvariable:] `HOME` (__nicht__ aber `PWD` und __nicht__ das Arbeitsverzeichnis selbst) bei der Ausführung auf '''/root''' gesetzt und es wird erschwert, dass eventuell Konfigurationsdateien im [:Homeverzeichnis:] des Benutzers überschrieben werden. * Die Option `-i` inkludiert `-H`, setzt aber zusätzlich das Arbeitsverzeichnis auf den Ordner '''/root/'''. Diese Option ist fast immer gut, ausgenommen man möchte [#Homeverzeichnis-zerschossen im Homeverzeichnis eines normalen Benutzers etwas reparieren]. {{{#!vorlage Warnung Die Verwendung der vorgestellten oder weiterer Optionen macht aus dem Befehl `sudo` __kein__ gefahrlos, unkritisch oder gedankenlos anwendbares Werkzeug! Nach Verwendung eines Programms mit `sudo` kann der Desktop unbenutzbar werden, z.B. wenn für die GUI wichtige Dateien des normalen Benutzers verändert werden. Diese Gefahr verschärft und steigert sich bei Programmen mit umfangreichem Funktionsumfang und immer bei Programmen mit grafischer Oberfläche durch unerkannte Fehler im riesigen aktiven Programmumfang solcher Software im Vergleich zu GNU-Programmen für die Kommandozeile. Der Verwendung von '''sudo''' mit Programmen mit grafischer Oberfläche wird deshalb dringend widerraten! }}} Beispiele[1]: {{{#!vorlage Befehl sudo nano # öffnet den Editor nano im Terminal unter dem Benutzer root sudo cp /var/log/foo.log /var/log/foo.old # kopiert eine Datei im Verzeichnis /var/log sudo apt update # aktualisiert die Liste der Pakete in den Paketquellen }}} Der Befehl `sudo` fordert zur Eingabe des Passwortes des Aufrufers auf, merkt sich aber eine erfolgreiche Authentifizierung für eine kurze Dauer auch für andere Programme/Aktionen. [[Anker(M5) ]] === M5: sudoedit === Zum Editieren einer sonst nicht bearbeitbaren Datei kann man im Terminal den Befehl `sudoedit` oder `sudo` mit der Option `-e` einsetzen. Beispiele: {{{#!vorlage Befehl sudoedit /etc/irgendwo/irgendwas.conf EDITOR=gedit sudoedit /etc/irgendwo/irgendwas.conf EDITOR=gedit sudo -e /etc/irgendwo/irgendwas.conf }}} Man wird zur Eingabe des eigenen Passwortes aufgefordert. Es wird der per [:Umgebungsvariable:] festgelegte Editor oder standardmäßig [:Nano:] verwendet. Details siehe [:sudo/#Editieren-von-Dateien-unter-Sudo-Rechten-sudoedit:]. Man darf auch einen GUI-Editor gefahrlos einsetzen, weil bei dieser Methode der Editor selbst niemals mit Root-Rechten läuft. Die Root-Rechte werden bei dieser Methode nur benutzt, um von der zu bearbeitenden Datei eine für den normalen Benutzer les- und schreibbare Arbeitskopie zu erstellen, welche nach Bearbeitung die ursprüngliche Datei unter Erhaltung deren ursprünglicher Besitzverhältnisse und Dateirechte ersetzt. Diese Methode vermeidet sehr sicher unerwünschte Nebenwirkungen. Eine Alternative zu `sudoedit` ist die [#M7-Das-GVFS-Protokoll-admin Verwendung des admin://-Protokolls]. [[Anker(M6) ]] == M6: Policy Kit == [:PolicyKit:Policy Kit] bietet einen zum klassischen Weg des Benutzerwechsels (z.B. über `sudo`) alternativen Weg mit seinem Dienstprogramm `pkexec`. Während `sudo` immer den Gesamtumfang der Root-Rechte bereit stellt bzw. die Programme/Befehle mit Allmacht ausführt, ermöglicht Policy Kit eine feinere Zuteilung der Rechte; d.h. das Programm erhält nur die Fähigkeiten, welche es zur Ausführung der spezifischen Aufgabe wirklich benötigt. Allerdings ist diese Methode nicht wie bei `sudo` universell anwendbar, vielmehr ist bereits bei der Entwicklung des Programms die Zusammenarbeit mit Policy Kit zu berücksichtigen; dies wurde realisiert z.B. bei den Programmen mit grafischer Oberfläche [:Synaptic:] und [:GParted:], während andere grafische Programme wie z.B. [:Gedit:] und [:Nautilus:] ganz bewusst aus Sicherheitsgründen mit `pkexec` unter X11 oder Wayland nicht starten. Der Befehl `pkexec` wird dem auszuführenden Befehl wie in den folgenden Beispielen einfach vorangestellt: {{{#!vorlage Befehl pkexec nano # öffnet den Editor nano im Terminal mit Root-Rechten pkexec cp /var/log/foo.log /var/log/foo.old # kopiert eine Datei im Verzeichnis /var/log pkexec apt update # aktualisiert die Liste der aus den Paketquellen verfügbaren Pakete }}} Manche GUI-Orogramme, z.B. auch `Synaptic` fordern nach dem normalen Start in der Desktop-Umgebung von sich aus per `pkexec` die benötigten zusätzliche Rechte an. Solche Programme sollte man nicht mit vorangestelltem `sudo` oder `pkexec` starten. Der Befehl `pkexec` fordert bei Bedarf bei jedem Aufruf zur Eingabe des Passwortes eines (bei mehreren möglichen auch auswählbaren) Administrators auf, merkt sich aber eine erfolgreiche Authentifizierung nur für diese spezifische Aktion für eine kurze Dauer. In Gegensatz zu `sudo` müssen andere Aktionen immer erneut autorisiert werden. Um mittels `pkexec` ein dafür noch nicht vorgesehenes Programm PROGRAMM mit grafischer Oberfläche auszuführen, muss man entweder Policy Kit für das jeweilige Programm konfigurieren oder eine besondere Aufrufweise benutzen. Beide Methoden verletzen die Prinzipien dieses Artikels, und ihrer Anwendung wird daher hier widerraten. Das Programm `pkexec` verwirklicht und konkretisiert somit auf technischer Ebene den alten Ratschlag > „Starte niemals ein Programm mit grafischer Oberfläche als `root`!“ zu mindestens teilweise: * Aus einem Fehlschlag des Befehls "`pkexec PROGRAMM`" darf/sollte man als plausibel ableiten, dass dann erst recht "`sudo PROGRAMM`" leichtsinnig und möglicherweise schädlich wäre! [[Anker(M7) ]] == M7: Das GVFS-Protokoll admin:// == Ubuntu bzw. Derivate, die das [:gio:"Gnome Virtual File System"] (kurz: GVFS) verwenden, können seit [:17.04:] das Protokoll `admin://` zum Öffnen bzw. Editieren von Dateien nutzen. GVFS ist standardmäßig bei Ubuntu und bei den auf GTK basierenden Desktops installiert, allerdings nicht unter Kubuntu oder anderen Qt-basierten Desktops. Weitere Informationen sind im Wikiartikel zu [:gio:] zu finden. Man benutzt dieses Protokoll entweder durch direkte Verwendung auf einer Kommandozeile oder über einen grafischen Dateimanager. In allen Fällen läuft ein so gestartetes Programm nicht unter `root`, sondern unter dem normalen Benutzer und kommuniziert über D-Bus mit dem Dienst `gvfsd-admin`. === admin per Kommandozeile === Der Bezeichner '''`admin://`''' wird einfach dem Namen der zu bearbeitenden Datei vorangestellt. Mit dem Befehl [[Vorlage(Befehl, "gedit admin:///etc/default/grub" ) ]] würde nach Eingabe eines mit `pkexec` abgefragten Passworts die Datei (hier als Beispiel) '''/etc/default/grub''' im Editor `gedit` bearbeitbar geöffnet. Das funktioniert neben [:Gedit:] auch mit Standardeditoren einiger Ubuntu-Derivate wie z.B. [:Pluma:] oder [:FeatherPad:], nicht jedoch bei Kubuntu mit [:Kate:] und auch nicht bei Xubuntu mit [:MousePad:]. Das GVFS-Protokoll `admin://` verhält sich an der Oberfläche somit in etwa wie eine „pkexec-Version von sudoedit“. In ähnlicher Weise kann man auch die Dateimanager [:Caja:], [:Nautilus:] und [:Nemo:] sowie "PCman File Manager Qt" mit diesem Protokoll benutzen, z.B. öffnet [[Vorlage(Befehl,"nautilus admin:///" ) ]] das Wurzelverzeichnis `"/"` in einem Fenster, welches auch die Navigation in sonst unzugängliche Order erlaubt. Man benutzt hierfür aber besser die anschließend beschriebene Arbeitsweise, die keinen vorherigen Start eines Terminals erfordert. === admin per Dateimanager === Die auf GTK beruhenden Dateimanager (jedenfalls [:Caja:], [:Nautilus:], [:Nemo:]) lassen sich in einen besonderen Modus umschalten, indem man den Ort `admin:///` (bei Nautilus „Administratoren-Wurzelordner“ genannt) öffnet. Dazu schaltet man die Adressanzeige mit den Tasten [[Vorlage(Tasten, Strg+L ) ]] um auf die Ortseingabe und gibt diese Bezeichnung ein und schließt das mit der Eingabetaste [[Vorlage(Tasten, Enter ) ]] ab. Man erhält ggf. eine oder mehrere Abfragen für das Passwort eines Administrators. Danach kann man durch Navigation in diesem Fenster für normale Benutzer gesperrte Ordner betreten, überall als `root` Dateien anlegen und löschen und auch Textdateien zur Bearbeitung öffnen und erneut abspeichern. Diese etwas komplizierte Bedienung muss man nur einmal ausführen, wenn man sich den „Administratoren-Wurzelordner“ per [[Vorlage(Tasten, Strg+D ) ]] als Lesezeichen ablegt und sinnvoll benennt (z.B. als ''„/ als root“''). Der Dateimanager [:Thunar:] lässt sich zwar ebenso bedienen, allerdings kommt es leider bei der Benutzung des ertüchtigten Fensters zu einer Fehlermeldung und Fehlfunktion. Der Dateimanager "PCman File Manager Qt" von Lubuntu (LXQt) lässt sich ebenso bedienen, jedoch nicht [:Dolphin:] und andere Dateimanager von Kubuntu und auf KDE beruhenden Derivaten. [[Anker(M8) ]] == M8: GUI-Werkzeuge == Grundsätzlich sollte man keine GUI-Programme wie z.B. Dateimanager oder Editoren selbst als `root` starten, also nicht die Methoden M4 oder M6 mit GUI-Programmen anwenden, sondern die hier anschließend genannten Alternativen verwenden. Aktuelle-Versionen von Ubuntu verwenden standardmäßig ab Ubuntu 22.04 LTS Wayland und frühere den X-Server als Basis für grafische Desktopumgebungen; man kann aber immer bei der Anmeldung durch Auswahl der Session wählen. Einige Compositoren für Wayland, z.B. Mutter (bei Ubuntu mit GNOME) und Kwin (bei Kubuntu), blockieren die Ausführung grafischer Programme unter dem Benutzer `root`. Dies trifft nicht generell zu für Wayland und überhaupt nicht für X11. Außerdem laufen auf Wayland-Systemen mit den genannten Compositoren auch nicht alle Programme nativ unter diesen, sondern es wird ggf. der X-Server [:Wayland/#Xwayland:Xwayland] gestartet, bei dem alle Probleme wie unter anderen [:XServer:X-Servern] auftreten können. Es wird daher grundsätzlich empfohlen, auch unter Wayland wie unter X11 keine GUI-Programme mit [#M4-sudo sudo] zu starten. Der Start von darauf nicht vorbereiteten grafischen Programmen per `pkexec` ist ohnehin nicht möglich, sondern wird von [#M6-Policy-Kit Policy Kit] beabsichtigt blockiert. Einige Dateimanager unterstützen per Kontextmenü manche Arbeiten mit Root-Rechten: === Nautilus === Der GNOME-Desktiop verwendet [:Nautilus:], dieser verlangt beim Betreten eines gesperrten Ordners per [#M6-Policy-Kit Policy Kit] das Passwort eines Administrators. Nach erfolgreicher Authentifizierung kann man Dateien mit Root-Rechten anlegen und löschen sowie über das [#M7-Das-GVFS-Protokoll-admin GVFS-Protokoll `admin://`] ändern, ohne dass dafür Nautilus selbst oder aus Nautilus gestartete Programme als `root` ausgeführt werden. Die Anwendung dieser Methode ist daher genau so sicher oder unsicher wie die direkte Verwendung [#M7-GVFS-Protokoll-admin des Protokolls `admin://`]. Optional kann man diese Bearbeitungsaufgaben als Menüpunkte in die Bedienoberfläche integrieren; siehe [:Nautilus#Mit-Root-Rechten-arbeiten:] und [:nautilus-admin:]. === Caja === Der bei Ubuntu Mate verwendete Dateimanager [:Caja:] hat standardmäßig im Kontextmenü Menüpunkte für das Arbeiten als `root`. Bei der Verwendung dieser Menüpunkte wird immer ein Programm unter dem Benutzer `root` gestartet, entweder Caja selbst, oder ein Editor wie Pluma oder ein anderes Programm. Dies ist immer leichtsinnig und kann manchmal schädlich sein und sollte daher besser vermieden werden. Die Verwendung [#M7-GVFS-Protokoll-admin des Protokolls `admin://`] ist dem bequemen Weg über das Kontextmenü von Caja vorzuziehen, weil sicherer. Es wird empfohlen, die betreffenden Einträge im Kontextmenü nicht zu verwenden, sondern sie auszublenden, um Gefährdungen durch deren irrtümlichen Gebrauch vorzubeugen. === Nemo === Der z.B. bei Ubuntu Budgie eingesetzte Dateimanager [:Nemo:] ermöglicht ebenfalls das Arbeiten als `root` über das Kontextmenü. Man muss bei der Aktivierung dieser Option einen Warnhinweis bestätigen und erhält dann ohne Eingabe eines Passwortes ein neues Fenster mit rotem Warnbalken. Dieses neue Fenster gehört zu einer weiteren Instanz von Nemo und wird unter dem Benutzer `root` ausgeführt; jede Datei, welche aus diesem Fenster heraus z.B. mit einem Editor geöffnet wird, startet ein weiteres Programm unter dem Benutzer `root`. Dies ist immer leichtsinnig und kann manchmal schädlich sein und sollte daher besser vermieden werden. Die Verwendung [#M7-GVFS-Protokoll-admin des Protokolls `admin://`] ist dem bequemen Weg über Nemo vorzuziehen, weil sicherer. Es wird empfohlen, die betreffenden Einträge im Kontextmenü nicht zu verwenden, sondern sie auszublenden, um Gefährdungen durch deren irrtümlichen Gebrauch vorzubeugen. === Thunar === Der Dateimanager [:Thunar:] bietet keine Menüpunkte für Arbeiten als Root an. Er kann mit Root-Rechten gestartet werden und läuft dann natürlich unter dem Benutzer `root`. Dies ist immer leichtsinnig und kann manchmal schädlich sein und sollte daher besser vermieden werden. Die Verwendung [#M7-GVFS-Protokoll-admin des Protokolls `admin://`] ist bei diesem Programm vorgesehen; leider kommt es dabei aber zu Fehlermeldungen und Fehlfunktionen. Unter Xubuntu verwendet man daher besser keine GUI-Unterstützung beim Arbeiten als Root. === Dolphin === Kubuntu ab [:18.04:] verhält sich restriktiver als Ubuntu und andere Derivate. So ist das Ausführen des Dateimanagers [:Dolphin:] oder der Editoren [:Kate:] und KWrite weder mit `sudo` noch mit `pkexec` möglich. Man erhält eine Fehlermeldung wie ''"Executing Kate as root is not possible."''. Allerdings kann man sichtbare Dateien, zu deren Bearbeitung man als normaler Benutzer aber nicht berechtigt ist, regulär in [:Kate:] öffnen und wird dann beim Speichern nach dem Passwort eines [:Administrator:Administrators] gefragt. === PCmanFM-Qt === [:Lubuntu:] mit [:LXqt:] verwendet als Dateimanager `PCmanFM-Qt`, dieser bietet keine Menüpunkte für Arbeiten als Root an, beherrscht allerdings [#M7-GVFS-Protokoll-admin das Protokoll `admin://`] durch Eingabe für den Ort. Unter Lubuntu gibt es mit `lxqt-sudo` (oder abgekürzt `lxsudo`) ein spezielles Verfahren zur Ausführung von Programmen mit administrativen Rechten. Dies funktioniert technisch auch für grafische Anwendungen. Die Bedienung ähnelt [:PolicyKit:Policy Kit], jedoch ist unklar, wie es tatsächlich funktioniert und wird daher aus sicherheitstechnischer Sicht hier nicht bewertet. Wegen fehlender Erkenntnisse ist seine Benutzung aber immer leichtsinnig und kann möglicherweise schädlich sein und sollte daher besser vermieden werden. Die Verwendung von [#M5-sudoedit sudoedit] ist vorzuziehen. = Praktische Beispiele = == Systemdatei mit Editor bearbeiten == Als konkretes Beispiel wird hier [:fstab:die Datei '''/etc/fstab'''] verwendet; die grundsätzliche Arbeitsweise kann aber auf jede Konfigurationsdatei übertragen werden. Bei allen Ubuntu-Systemen (Server wie Desktops) kann jeder normale Benutzer -- der allerdings ein Administrator sein muss -- die hier anschließend beschriebene auf [#M5 Methode `sudoedit`] basierende Prozedur anwenden. Bei Systemen mit Desktop kann man alternativ [#M7 das Protokoll `admin://`] einsetzen. Für diese Aufgabe wird hier aber als sicherste und universellste Arbeitsweise empfohlen: 1. Man lese – sofern nicht bereits bekannt – den Abschnitt [#Gefahren-und-Vorsichtsmaßnahmen Gefahren und Vorsichtsmaßnahmen]. 1. Man starte ein Terminal[1]. In jeder Desktop-Umgebung geht das mit den Tasten [[Vorlage(Tasten, Strg+Alt+T ) ]], alternativ kann man andere, für den jeweiligen Desktop spezifische Methoden benutzen oder auf eine virtuelle Konsole wechseln. 1. Optional aber empfehlenswert: Man erstellt eine Kopie der zu bearbeitenden Systemdatei `PFAD-zur/SYSTEMDATEI`, dafür muss diese für normale Benutzer lesbar sein und man muss für die Kopie einen Ordner SICHERUNG wählen, in dem man Dateien anlegen darf, z.B. im eigenen [:Homeverzeichnis:]. Den Namen der Kopie kann man frei wählen: \\ {{{ cp PFAD-zur/SYSTEMDATEI SICHERUNG/SYSTEMDATEI~HINWEIS # Allgemeines Muster cp /etc/fstab ~/fstab~$(date --iso) # Konkreter Befehl }}} Der konkrete Befehl sichert die Systemdatei in eine Datei im eigenen Homeverzeichnis mit dem aktuellen Datum als HINWEIS. 1. Bearbeitung mit dem eigenen Lieblingseditor (hier beispielhaft: nano): [[Vorlage(Befehl, "EDITOR=nano sudoedit /etc/fstab" ) ]] Siehe auch: [#M5 sudoedit]. Man editiert konkret in einer automatisch angelegten Kopie, die beim Abspeichern an die Stelle der ursprünglichen Datei verschoben wird. Benutzer und Dateirechte werden automatisch richtig angepasst.\\ Wenn man über eine Desktopumgebung verfügt, kann man auch einen grafischen Editor (hier beispielhaft: gedit) benutzen: [[Vorlage(Befehl, "EDITOR=gedit sudoedit /etc/fstab" ) ]] 1. Das Terminal kann man nun schließen. Wenn man diese Prozedur oft benötigt, kann man sich optional die Eingabe etwas vereinfachen, indem man sich wie im Artikel [:sudo/#sudoedit:] gezeigt eine Abkürzung (Alias) definiert. Dann schreibt man beim Punkt 3 nur noch: [[Vorlage(Befehl, "rootedit /etc/fstab" ) ]] Wenn man eine Desktopumgebung benutzt, welche die Spezifikationen von [https://freedesktop.org freedesktop.org] {en} beachtet, kann man optional diese Prozedur in das Kontextmenü seines Dateimanagers integrieren; man muss dafür nur eine [:Desktop-Dateien/Beispiele/Systemdatei_bearbeiten:Desktop-Datei für sudoedit bzw. `admin://`] anlegen. Manche Dateimanager können über "Custom Actions" (o.ä.) auch selbst solche Desktop-Dateien erstellen. [#M7 Die Alternative über `admin://`] mit vergleichbar gutem Sicherheitsniveau kann bei manchen Desktop-Umgebungen auch über den Befehls-Schnellstarter [[Vorlage(Tasten, Alt+F2) ]] oder mit der vorstehend verlinkten Desktop-Datei benutzt werden. == System aktualisieren == Wenn ein Administrator eine anstehende reguläre Aktualisierung des Systems manuell durchführen möchte, kann auf jedem korrekt installiertem Ubuntu-System diese empfohlene Prozedur angewendet werden: 1. Man startet ein Terminal[1]. 1. Paketbeschreibungen aktualisieren: [[Vorlage(Befehl, "sudo apt update" ) ]] 1. Installierte Pakete aktualisieren und ggf. dafür erforderliche neue Pakete installieren: [[Vorlage(Befehl, "sudo apt upgrade" ) ]] 1. Optional nicht mehr benötigte Pakete entfernen: [[Vorlage(Befehl, "sudo apt autoremove" ) ]] Bei Ubuntu benötigt man für diese Aufgabe keine weiteren Befehle an `apt`, auch niemals `full-upgrade` oder gar `dist-upgrade`. Dies ist eine Eigenschaft des Ubuntu-Paketsystems und kann bei anderen Distributionen anders sein. Wer statt [:apt/apt:apt] das ältere und vielseitigere Programm [:apt-get:] bevorzugt, kann auch dieses für diese Aufgabe problemlos verwenden. Beachte: Diese Prozedur für die tägliche Praxis entfernt veraltete Linux-Kernel nicht automatisch; diese können sich ansammeln und ggf. das Verzeichnis '''/boot/''' verstopfen. Die automatische Entfernung nicht mehr benötigter Kernel ist eine Serviceleistung der standardmäßigen grafischen Aktualisierung; wer die manuelle Arbeitsweise schätzt, muss daher auch selber dieses Detail beobachten. = Problembehebung = == Kein Administrator vorhanden == Sollte -- aus welchen Gründen auch immer -- kein Administrator mehr im System vorhanden sein, kann man mit den Methoden [#M1 M1] oder [#M2 M2] einen anlegen oder einen vorhandenen Benutzer dazu ertüchtigen. Siehe auch: [:Administrator/#Notfall:] == Homeverzeichnis zerschossen == Ob durch fehlerhafte Anwendung der Root-Rechte bereits [:Homeverzeichnis/#Rechte-korrigieren:Schäden im eigenen :Homeverzeichnis] entstanden sind, kann man bei Ubuntu als normaler Benutzer mit diesen Befehlen prüfen: {{{#!vorlage Befehl find ~ ! -user $USER -ls find ~ ! -group $USER -ls }}} So gefundene Dateien fremder Benutzer, z.B. von `root`, lassen sich mit den Befehlen [:chown:], [:chmod:] und [:rm:] reparieren oder löschen; dazu sind diese Befehle natürlich als `root` auszuführen. Siehe auch: [:Homeverzeichnis/#Rechte-korrigieren:] = Links = * [https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5 Warum kein GUI-Programm als `root` laufen sollte] {en} – Erläuterung das GUI-Entwicklers Emmanuele Bassi zum Thema * [:Administrator:] * [:sudo:] * [:sudo/#Editieren-von-Dateien-unter-Sudo-Rechten-sudoedit:sudoedit] * [:PolicyKit:] * [:PolicyKit/#pkexec:] * [:Desktop-Dateien/Beispiele/Systemdatei_bearbeiten:Systemdatei bearbeiten] – Desktop-Dateien zur Einbindung von [#M5 sudoedit (M5)] und [#M7 admin:// (M7)] in grafische Desktops * [gnomeprojects:gvfs:Gnome Virtual File System] {en} ## Diese Verweise stammen noch aus der alten Version des Artikels (vor 01.06.2023) und sollen in den Artikeln zu Lubuntu/LXQt eine neue Heimat finden: ## * https://github.com/lxqt/lxqt-sudo ## * https://manual.lubuntu.me/lts/3/3.1/3.1.7/lxqt-sudo.html #tag: System, Shell, Sicherheit