Linux Berechtigungen bei sudo, su und root richtig einsetzen

Ein vorangestelltes sudo verändert weit mehr als die Kennung, unter der ein Prozess läuft. Suchpfad, Heimatverzeichnis und Umgebungsvariablen können sich ändern. Außerdem entsteht ein Eintrag im Systemprotokoll. Die einmal eingegebene Kennung bleibt für ein begrenztes Zeitfenster gespeichert, bevor sudo erneut nachfragt. Viele Störungen auf Linux-Systemen haben genau hier ihre Ursache. Ein Skript findet ein Programm plötzlich nicht mehr. Eine Konfigurationsdatei landet im falschen Heimatverzeichnis. Dabei scheitert eine Umleitung an fehlenden Schreibrechten, obwohl der Aufrufer den Befehl davor mit sudo gestartet hat.

Die drei üblichen Wege zu erhöhten Rechten unterscheiden sich in genau diesen Punkten. su wechselt die Kennung. su mit Bindestrich baut zusätzlich eine frische Anmeldeumgebung auf. sudo führt ein einzelnes Kommando unter einem anderen Konto aus, nachdem es das Regelwerk in der sudoers-Datei geprüft hat. Ubuntu und die meisten davon abgeleiteten Systeme liefern das Rootkonto ohne gültiges Passwort aus, Debian nur dann, wenn bei der Installation kein Root-Passwort vergeben wurde. Auf solchen Systemen läuft su ins Leere. Die aktuelle stabile Fassung des klassischen sudo trägt die Nummer 1.9.17p2 vom Juli 2025. Die beiden Lücken CVE-2025-32462 und CVE-2025-32463 hat bereits die Vorgängerversion 1.9.17p1 geschlossen, Distributionen wie Debian liefern die Korrekturen auch für ältere Versionsnummern als Sicherheitsupdate aus. Ubuntu verwendet seit Version 25.10 und damit auch in 26.04 LTS allerdings die Rust-Neuentwicklung sudo-rs als Standard für den Befehl sudo. Das klassische Programm bleibt dort als sudo.ws installiert.

Was su, su mit Bindestrich und sudo mit der Umgebung machen

su ohne weitere Angabe wechselt die Benutzerkennung und startet eine Shell, die große Teile der bestehenden Umgebung übernimmt. Das Arbeitsverzeichnis bleibt stehen. Viele Variablen des aufrufenden Kontos wandern dabei mit. Der Suchpfad zeigt weiterhin auf die Verzeichnisse des alten Kontos. Genau daraus entsteht der Klassiker unter den Fehlermeldungen. Werkzeuge aus /usr/sbin wie ip, fdisk oder useradd melden ein command not found, obwohl das System sie längst installiert hat. Der Prompt zeigt zwar die Raute für root, die Umgebung passt jedoch nicht dazu.

Video abspielen: Linux Benutzer & Rechte endlich verstehen! sudo, Root, Gruppen & Benutzer erklärt

su -l räumt diesen Zustand auf. Der Aufruf bildet die Anmeldung nach und liest die Startdateien des Zielkontos. Danach setzt er HOME, SHELL, USER, LOGNAME und PATH neu. Die Sitzung landet im Heimatverzeichnis des Zielkontos. Für Wartungsarbeiten ist das die saubere Variante. sudo geht einen dritten Weg und setzt die Umgebung in der Voreinstellung zurück, gesteuert über die Option env_reset. Der Pfad kommt dabei aus secure_path in der sudoers-Datei. Eigene Variablen überleben nur, wenn env_keep sie ausdrücklich freigibt. Das klassische sudo erlaubt mit passender Regel zusätzlich einen Aufruf mit sudo -E. sudo-rs, der Standard unter Ubuntu 25.10 und 26.04 LTS, übergeht diese Option dagegen mit einer Warnung und startet das Kommando trotzdem mit zurückgesetzter Umgebung.

sudo -i gegen sudo -s und das gesperrte Rootkonto

sudo -s startet eine Shell mit Rootrechten und behält das Arbeitsverzeichnis bei, bildet aber keine Anmeldung nach. Weil env_reset in der Voreinstellung HOME auf das Zielkonto setzt, liest eine Bash dabei /root/.bashrc, den Suchpfad liefert secure_path. sudo -i bildet eine echte Anmeldung als root nach und liest dabei /root/.profile. Danach wechselt der Aufruf nach /root und liefert einen Prompt, der den Status sichtbar macht. Für Wartungssitzungen gilt sudo -i als der robustere Weg, weil die Umgebung des Rootkontos deutlich schwerer zu vergiften ist. Die verbreitete Kombination sudo su kostet einen zusätzlichen Prozess ohne Gewinn.

Ubuntu, Linux Mint und viele abgeleitete Systeme geben das Rootkonto ohne gültiges Passwort aus. Debian sperrt es nur dann, wenn bei der Installation kein Root-Passwort vergeben wurde. Das Passwortfeld in /etc/shadow trägt ein Ausrufezeichen. Der Aufruf passwd -S root meldet den Status L für gesperrt. Eine Anmeldung über su scheitert an der fehlenden Kennung. Die Rechte kommen aus der Gruppenmitgliedschaft. Unter Debian und Ubuntu heißt die zuständige Gruppe sudo. Unter Fedora, RHEL, Arch und openSUSE trägt sie den Namen wheel. Der Vorteil liegt in der Zuordnung. Jeder Zugriff trägt einen Namen. Niemand teilt dabei ein gemeinsames Passwort. Der Entzug der Rechte braucht daher nur das Entfernen des Kontos aus der zuständigen Gruppe.

Die Datei sudoers und warum nur visudo sie öffnet

Das Regelwerk steht in /etc/sudoers. Ein Tippfehler in dieser Datei kappt im schlimmsten Fall jeden Zugang zu erhöhten Rechten. Denn sudo verweigert eine Datei mit fehlerhafter Syntax komplett und wertet keine einzige Regel daraus aus. visudo öffnet sie deswegen mit einer Sperre gegen gleichzeitige Bearbeitung und prüft die Syntax vor dem Speichern. Bei einem Fehler nennt das Werkzeug die Zeilennummer und bietet an, die Bearbeitung fortzusetzen oder die Änderung zu verwerfen. Ohne diese Prüfung bleibt im Ernstfall nur der Weg über den Wiederherstellungsmodus oder eine Live-Umgebung. Daneben hilft pkexec, sofern die grafische Oberfläche noch erreichbar ist.

Änderungen gehören heute in eigene Dateien unter /etc/sudoers.d/, eingebunden über die Zeile @includedir in der Hauptdatei. visudo -f /etc/sudoers.d/wartung legt eine solche Datei an und prüft sie genauso. Zwei Fallen lauern an dieser Stelle. Dateinamen mit einem Punkt oder mit einer Tilde am Ende werden beim Einlesen übergangen. Eine Datei namens wartung.conf bleibt also ohne jede Wirkung. Die Rechte müssen bei 0440 liegen, andernfalls verweigert sudo den Dienst. visudo -c prüft die Hauptdatei samt aller eingebundenen Verzeichnisse und eignet sich als kurzer Test nach jeder Änderung.

Rechte gezielt vergeben und das Zeitfenster der Authentifizierung

Die Zeile ALL=(ALL:ALL) ALL gibt einem Konto den vollen Zugriff auf jedes Kommando. Für eine Person, die nur einen Dienst neu starten soll, genügt eine enge Regel wie wartung ALL=(root) /usr/bin/systemctl restart nginx. Aliase für Kommandos und Konten halten größere Regelwerke lesbar. Vorsicht gilt bei Programmen, aus denen sich eine Shell öffnen lässt. Editoren, less, find oder tar heben die gewünschte Beschränkung wieder auf, weil sie eine Shell mit Rootrechten starten können. Platzhalter in Pfaden erweitern eine Regel oft weiter als beabsichtigt. sudo -l zeigt jederzeit, welche Kommandos das eigene Konto tatsächlich ausführen darf.

Nach der ersten Eingabe merkt sich sudo die Authentifizierung. Beim klassischen sudo liegt der Standardwert für timestamp_timeout bei fünf Minuten. Debian und Ubuntu setzen in ihren Paketen 15 Minuten, sudo-rs ebenfalls. Dort verkürzt der Eintrag Defaults timestamp_timeout=5 dieses Fenster deutlich. Der Wert 0 erzwingt bei jedem Aufruf eine neue Eingabe. Ein negativer Wert lässt den Zeitstempel niemals ablaufen und gehört auf Mehrbenutzersystemen nicht in die Konfiguration. sudo -k verwirft den Zeitstempel sofort, sudo -K entfernt ihn vollständig. Die Marken liegen unter /run/sudo/ts und gelten je nach Einstellung nur für das aktuelle Terminal. Raspberry Pi OS hat mit der Ausgabe vom April 2026 das passwortlose sudo in der Voreinstellung abgeschaltet.

Pipes, Umleitungen und der Umweg über tee

sudo echo eintrag >> /etc/hosts scheitert mit einer Meldung über fehlende Rechte, obwohl sudo im Spiel ist. Die Shell des aufrufenden Kontos wertet die Umleitung aus, bevor sudo überhaupt startet. Genau diese Shell besitzt keine Schreibrechte an der Zieldatei. Gleiches gilt für eine Pipe, deren rechtes Glied ohne erhöhte Rechte läuft. Der übliche Ausweg führt über tee. Der Aufruf echo eintrag | sudo tee -a /etc/hosts übergibt den Text an ein Programm, das selbst mit Rootrechten schreibt. Ein angehängtes > /dev/null unterdrückt danach die zusätzliche Ausgabe auf dem Terminal.

Jeder Aufruf hinterlässt eine Spur. Debian und Ubuntu schreiben nach /var/log/auth.log, RHEL und Fedora nach /var/log/secure, journalctl _COMM=sudo liefert dieselben Einträge aus dem Journal. Protokolliert werden das aufrufende Konto, Terminal, Arbeitsverzeichnis, Zielkonto und die komplette Kommandozeile, gescheiterte Passworteingaben tauchen dort ebenfalls auf. Das klassische sudo kann über die Optionen log_input und log_output zusätzlich die Ein- und Ausgabe einer Sitzung aufzeichnen. Diese Protokolle liegen unter /var/log/sudo-io und lassen sich über sudoreplay abspielen. sudo-rs, der Standard unter Ubuntu 25.10 und 26.04 LTS, beherrscht diese Aufzeichnung nicht und schreibt nur ins Systemprotokoll. Ein lokales Protokoll lässt sich mit Rootrechten ändern, weshalb sicherheitskritische Umgebungen die Daten an einen getrennten Protokollserver senden.

Das SUID-Bit, polkit und der Fehler chmod 777

Das SUID-Bit lässt ein Programm mit den Rechten seines Eigentümers laufen, unabhängig davon, wer es startet. ls -l zeigt an der Stelle des Ausführungsrechts ein kleines s, gesetzt wird das Bit über chmod u+s. passwd braucht diesen Mechanismus, weil das Ändern eines Passworts an /etc/shadow rührt. Jeder Fehler in einem solchen Programm öffnet direkt den Weg zu Rootrechten. Die Lücke PwnKit in pkexec (CVE-2021-4034) steckte seit 2009 im Code und betraf praktisch jede große Distribution. Der Aufruf find / -perm -4000 -type f 2>/dev/null listet die vorhandenen Kandidaten auf. Capabilities über setcap und die Mount-Option nosuid begrenzen anschließend den Bestand dauerhaft.

Grafische Programme holen ihre Rechte über polkit. Der Dialog mit der Passwortabfrage gehört zu diesem Dienst. Die zugehörigen Aktionen liegen als XML-Dateien unter /usr/share/polkit-1/actions/. Eigene Regeln finden sich dagegen in /etc/polkit-1/rules.d/. Eine Aktion verlangt je nach Einstellung eine erneute Freigabe oder merkt sich die Antwort für die laufende Sitzung. Der Griff zu chmod 777 löst dagegen kein Rechteproblem. OpenSSH verweigert private Schlüssel mit zu offenen Rechten. Auch sudo lehnt eine sudoers-Datei außerhalb von 0440 ab. In Webverzeichnissen erlaubt eine solche Einstellung jedem Konto das Überschreiben der Dateien. Passende Eigentümer, Gruppenrechte wie 640 oder 750 und bei Bedarf ACLs über setfacl lösen den Fall sauber.

Fazit zu Linux Berechtigungen bei sudo, su und root

Der Unterschied zwischen den drei Wegen liegt in der Umgebung und in der Nachvollziehbarkeit. su -l und sudo -i bauen eine frische Anmeldeumgebung auf. su ohne Bindestrich schleppt dagegen den alten Suchpfad mit und erzeugt daher die bekannten Fehlermeldungen. sudo -s liegt dazwischen, weil die Shell zwar den Pfad aus secure_path erhält, aber keine Anmeldung nachbildet und im alten Arbeitsverzeichnis bleibt. Eng gefasste Regeln in eigenen Dateien unter /etc/sudoers.d/, geprüft mit visudo, ersetzen den pauschalen Vollzugriff und halten das Protokoll aussagekräftig. Umleitungen brauchen den Umweg über tee. SUID-Bits gehören regelmäßig auf den Prüfstand. Ein chmod 777 verschiebt ein Rechteproblem außerdem nur an eine andere Stelle.