Eine der Stärken von Linux liegt in allgemeinem daran, dass das System seit Urzeiten als Mehrbenutzersystem konzipiert ist. User starten Anwendungen im Rahmen ihrer Benutzerrechte, sodass diese in der Regel nichts am System ändern können. Malware beeinträchtigt somit höchstens den Datenbestand des Users, der diese ausführt. Dennoch machen wir Linuxer immer wieder gerne ein Türchen auf: Sobald wir beispielsweise einen Editor mit Root-Rechten starten, etwa um eine Konfigurationsdatei zu bearbeiten, führen wir diesen mitsamt dem kompletten Toolkit (also GTK oder Qt) mit administrativen Rechten aus. Dadurch läuft mehr Code mit administrativen Rechten, als eigentlich nötig, daran ändert auch der Aufruf des Programms mit gksu oder gksudo nichts.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.

Der mit sudoedit gestartete Gedit-Editor arbeitet ohne Root-Rechte.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

Durch Eingabe von admin:// kommt man in den Administrations-Modus.
Für die Root-Rechte benötigt man natürlich auch administrative Rechte

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

Das Schloss-Symbol kennzeichnet besonders geschützte Ordner und Dateien.
Aus dem Dateimanager lassen sich dann geschützte Dateien bearbeiten.
Und natürlich auch in einem Texteditor mit Root-Rechten bearbeiten.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.

Vorheriger ArtikelÜberarbeiteter Raccon APK Downloader 4.0
Nächster ArtikelPeek erstellt auf einfache Art Screencasts als animiertes GIF-Bild und demächst als WebM-Video
Hallo, ich bin Christoph - Linux-User, Blogger und pragmatischer Fan freier Software. Wie ihr ohne Zweifel bemerkt haben solltet, schreibe ich hier über Linux im Allgemeinen, Ubuntu im Speziellen sowie Android und andere Internet-Themen. Wenn du Freude an meinen Artikel gefunden haben solltest, dann kannst du mir über Facebook, Twitter oder natürlich dem Blog folgen.

12 Kommentare

  1. Wird die .xprofile auch angewendet, wenn man Wayland als Displayserver verwendet, wie es bei Gnome 3.22 unter Fedora standardmäßig der Fall ist? Tante Google hat zu der Frage keine brauchbare Antwort geliefert.

  2. Für gedit ist es erforderlich, VISUAL auf gedit -s zu setzen, sonst funktioniert sudoedit nicht richtig, wenn gedit bereits geöffnet ist. Das Standardverhalten von gedit ist nämlich so, dass gedit beim Start prüft, ob bereits ein gedit-Prozess läuft, und falls ja, die Datei dann an den bestehenden Prozess übergibt und den neuen Prozess beendet. sudoedit denkt dann aber, die Bearbeitung der Datei sei bereits abgeschlossen.

    Gedit und andere Programme machen das deshalb, damit man z.B Tabs von einem Fenster in ein anderes verschieben kann und solche Dinge. Mit -s kann das abschalten und das Starten eines neuen Prozesses erzwingen, bei anderen Editoren schaut mal in die Manpage, ob es irgendein Flag für „new instance“ oder „standalone“ gibt.

    • Hi Saddy, meine Beiträge hier im Blog sind freier 😉 Nach (wenn ich mich recht erinnere über 60.000 Beiträgen im Ubuntuusers-Forum und Hunderten eigenen Beiträgen und unzähligen Edits im Wiki ist mir die Funktionsweise eines Wikis durchaus bewusst 🙂 Ich habe auch gar keine Kritik geäußert, sondern lediglich meine Verwunderung darüber zum Ausdruck bringen wollen, dass sudoedit mir (und unzähligen anderen Linux-Usern) bislang komplett durch die Lappen gegangen ist. Viele Grüße, Christoph.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein