ubuntuusers.de

mit Root-Rechten arbeiten

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

„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, 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 beschrieben.

Weitere typische Anwendungsfälle zum Arbeiten mit Root-Rechten sind beispielsweise:

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 Gruppe sudo ist. Die Gruppe der Administratoren und ob man selbst dazu gehört kann man einfach erfragen:

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.

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 (M1 … M8), von denen je nach Aufgabenstellung (A1 … A5), Situation und persönlichen Vorlieben die eine oder andere zweckmäßiger ist. (Vgl. Tabelle 1)

Gefahren und Vorsichtsmaßnahmen

Achtung!

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.

  2. 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 (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 X11 und Wayland, Kommunikationswege wie D-Bus, sowie gemeinsam genutzte Dienste, Programme, Dateien und Ordner.

  3. 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: 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.

⚓︎

Tabelle 1: Methoden für Aufgabenklassen
MethodeAufgabenklasseNeben-
wirkungen
GUIBemerkung
A1A2A3A4A5
M1: Root-Shell – Offline (nein)jaja 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: Root-Shell im Single-User-Modeja jaja ja nein + nein
M3: Root-Shell per Anmeldung ja jaja ja nein ++ nein
M4: sudo ja jaja ja nein ++ nein
M5: sudoedit nein janeinneinnein + (ja) (ja): Man kann in einer Desktop-Umgebung im Terminal mit sudoedit einen grafischen Editor benutzen.
M6: Policy Kit (ja) jaja ja nein ++ ja (ja): Nicht jedes Programm kann mit pkexec gestartet werden.
M7: GVFS-Protokoll admin:// nein janeinneinnein ++ ja
M8: GUI-Werkzeuge nein jaja 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 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.

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 sudo bzw. 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.

⚓︎

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.

⚓︎

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.

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

  3. 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 E .

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

  5. 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 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 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 Strg + Alt + Entf , was zu einem erneuten Start führt.

⚓︎

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 Strg + + F1 bis Strg + + F6 erreichbaren 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 sudo:

    sudo -i 
  • Der bei anderen Linux-Distributionen ebenfalls mögliche 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:

    su --login
    su -l
    su - 
  • Der ebenfalls mögliche Befehl

    pkexec bash -l 

    ist eine Anwendung des Verfahrens per 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

exit 

oder Strg + D verlassen, um in eine normale, unprivilegierte Shell zurück zu kehren.

sudo und sudoedit

Das Programm sudo ermöglicht nicht nur den 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 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.

⚓︎

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

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 im Homeverzeichnis eines normalen Benutzers etwas reparieren.

Achtung!

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]:

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.

⚓︎

M5: sudoedit

Zum Editieren einer sonst nicht bearbeitbaren Datei kann man im Terminal den Befehl sudoedit oder sudo mit der Option -e einsetzen. Beispiele:

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 (Abschnitt „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 Verwendung des admin://-Protokolls.

⚓︎

M6: Policy Kit

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:

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!

⚓︎

M7: Das GVFS-Protokoll admin://

Ubuntu bzw. Derivate, die das "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

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

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 Strg + L um auf die Ortseingabe und gibt diese Bezeichnung ein und schließt das mit der Eingabetaste 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 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.

⚓︎

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 Xwayland gestartet, bei dem alle Probleme wie unter anderen X-Servern auftreten können.

Es wird daher grundsätzlich empfohlen, auch unter Wayland wie unter X11 keine GUI-Programme mit sudo zu starten. Der Start von darauf nicht vorbereiteten grafischen Programmen per pkexec ist ohnehin nicht möglich, sondern wird von 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 Policy Kit das Passwort eines Administrators. Nach erfolgreicher Authentifizierung kann man Dateien mit Root-Rechten anlegen und löschen sowie über das 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 des Protokolls admin://. Optional kann man diese Bearbeitungsaufgaben als Menüpunkte in die Bedienoberfläche integrieren; siehe Nautilus (Abschnitt „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 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 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 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 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 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 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 sudoedit ist vorzuziehen.

Praktische Beispiele

Systemdatei mit Editor bearbeiten

Als konkretes Beispiel wird hier 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 Methode sudoedit basierende Prozedur anwenden. Bei Systemen mit Desktop kann man alternativ 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.

  2. Man starte ein Terminal[1]. In jeder Desktop-Umgebung geht das mit den Tasten Strg + Alt + T , alternativ kann man andere, für den jeweiligen Desktop spezifische Methoden benutzen oder auf eine virtuelle Konsole wechseln.

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

  4. Bearbeitung mit dem eigenen Lieblingseditor (hier beispielhaft: nano):

    EDITOR=nano sudoedit /etc/fstab 

    Siehe auch: 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:

    EDITOR=gedit sudoedit /etc/fstab 
  5. 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 (Abschnitt „sudoedit“) gezeigt eine Abkürzung (Alias) definiert. Dann schreibt man beim Punkt 3 nur noch:

rootedit /etc/fstab 

Wenn man eine Desktopumgebung benutzt, welche die Spezifikationen von freedesktop.org 🇬🇧 beachtet, kann man optional diese Prozedur in das Kontextmenü seines Dateimanagers integrieren; man muss dafür nur eine Desktop-Datei für sudoedit bzw. admin:// anlegen. Manche Dateimanager können über "Custom Actions" (o.ä.) auch selbst solche Desktop-Dateien erstellen.

Die Alternative über admin:// mit vergleichbar gutem Sicherheitsniveau kann bei manchen Desktop-Umgebungen auch über den Befehls-Schnellstarter 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].

  2. Paketbeschreibungen aktualisieren:

    sudo apt update 
  3. Installierte Pakete aktualisieren und ggf. dafür erforderliche neue Pakete installieren:

    sudo apt upgrade 
  4. Optional nicht mehr benötigte Pakete entfernen:

    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 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 oder M2 einen anlegen oder einen vorhandenen Benutzer dazu ertüchtigen. Siehe auch: Administrator (Abschnitt „Notfall“)

Homeverzeichnis zerschossen

Ob durch fehlerhafte Anwendung der Root-Rechte bereits Schäden im eigenen :Homeverzeichnis entstanden sind, kann man bei Ubuntu als normaler Benutzer mit diesen Befehlen prüfen:

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 (Abschnitt „Rechte-korrigieren“)

Diese Revision wurde am 1. Juni 2023 08:56 von kB erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Shell, System, Sicherheit