Linux Gruppen und Berechtigungen einfach erklärt

Linux Berechtigungen entscheiden bei jedem einzelnen Zugriff, wer eine Datei lesen, ändern oder ausführen darf. Sie tun das lautlos, und genau das macht sie tückisch: Falsch gesetzte Rechte fallen entweder gar nicht auf oder erst dann, wenn der Webserver eine leere Seite ausliefert. Dieser Artikel erklärt das Modell von Grund auf — Benutzer und Gruppen, das oktale System hinter chmod 755, den Unterschied zu chown und die drei Stellen, an denen es in der Praxis am häufigsten schiefgeht.

Linux Berechtigungen: drei Rechte, drei Klassen

Jede Datei und jedes Verzeichnis gehört genau einem Benutzer und genau einer Gruppe. Daraus ergeben sich drei Klassen, für die getrennt festgelegt wird, was erlaubt ist: der Besitzer, die Gruppe und alle anderen. Für jede dieser Klassen gibt es dieselben drei Rechte — lesen, schreiben, ausführen.

Bei Verzeichnissen bedeuten diese Rechte etwas anderes als bei Dateien, und das ist die erste Stolperfalle. Lesen heisst dort: den Inhalt auflisten. Schreiben heisst: Dateien anlegen und löschen. Und Ausführen heisst nicht etwa, dass das Verzeichnis startet, sondern dass ihr hindurchgehen und auf die Dateien darin zugreifen dürft. Ein Verzeichnis ohne Ausführungsrecht ist eine verschlossene Tür, auch wenn alles dahinter lesbar wäre.

Benutzer und Gruppen

Ein Benutzer ist jemand, der auf das System zugreift — eine Person oder ein Systemdienst. Eine Gruppe ist eine Sammlung von Benutzern. Der Sinn der Gruppe ist, Rechte nicht einzeln pflegen zu müssen: Wer dieselbe Aufgabe hat, kommt in dieselbe Gruppe, und die Rechte hängen an der Gruppe statt an jedem Konto einzeln.

Benutzer und Gruppen anzeigen

Die vorhandenen Benutzer stehen in /etc/passwd, die Gruppen in /etc/group. Beides sind einfache Textdateien, mehr zu ihrer Rolle im Dateisystem steht in unserem Beitrag zu den Linux Systemverzeichnissen.

cut -d: -f1 /etc/passwd
cat /etc/group

Welchen Gruppen ihr selbst angehört, sagt euch id oder groups ohne weitere Angaben.

Benutzer anlegen und wieder entfernen

Auf Debian und Ubuntu legt adduser einen Benutzer samt Homeverzeichnis an. Dabei entsteht standardmässig eine eigene Gruppe mit demselben Namen wie der Benutzer, die zur primären Gruppe wird — die Debian-Dokumentation nennt das Usergroups. Der Benutzer landet also nicht in einer allgemeinen Sammelgruppe.

sudo adduser benutzer

Zum Entfernen gehört das Gegenstück deluser. Das reine userdel aus dem passwd-Paket funktioniert zwar auch, lässt aber das Homeverzeichnis stehen, solange die Option -r fehlt. Wer die Daten des Kontos mit entfernen will, muss das ausdrücklich sagen:

sudo deluser --remove-home benutzer

Benutzer einer Gruppe hinzufügen

Zusätzliche Gruppen vergibt usermod. Die Option -a ist dabei nicht optional, sondern überlebenswichtig: Ohne sie ersetzt -G die vorhandene Gruppenliste, statt sie zu ergänzen — der Benutzer fliegt also aus allen Gruppen, die im Befehl nicht stehen. Die Handbuchseite von usermod weist ausdrücklich darauf hin.

sudo usermod -aG www-data benutzer

Zwei Dinge dazu. Erstens: Wer einen Benutzer in die Gruppe sudo aufnimmt, gibt ihm damit Zugriff auf das ganze System — das ist keine abgestufte Berechtigung, sondern der Generalschlüssel. Zweitens: Eine neu vergebene Gruppenmitgliedschaft greift erst in einer neuen Sitzung. Solange ihr eingeloggt bleibt, kennt eure Sitzung die alte Gruppenliste.

Korrektur: Eine Gruppe „ssh“ entscheidet nicht über den SSH-Zugang

In einer früheren Fassung dieses Artikels stand, ein Benutzer müsse für SSH-Zugang in die Gruppe ssh. Das stimmt so nicht. Die Handbuchseite zu sshd_config hält fest: „By default, login is allowed for all groups.“ Wer den Zugang auf eine Gruppe beschränken will, muss das selbst konfigurieren, über AllowGroups in /etc/ssh/sshd_config. Erst dann ist Login nur noch für Benutzer erlaubt, deren primäre oder zusätzliche Gruppe zum Muster passt.

# in /etc/ssh/sshd_config
AllowGroups sshusers

Das ist eine sinnvolle Massnahme, aber sie ersetzt die Grundlagen nicht. Wie ihr einen SSH-Zugang richtig absichert, steht in Sicher per SSH einloggen; wer noch einen Schritt weiter gehen will, findet in Server SSH Zugang mit YubiKey absichern die Variante mit Hardware-Token.

Das oktale System: 4, 2 und 1

Um Rechte zu setzen, wird meist das oktale System verwendet. Jedes der drei Rechte hat einen festen Wert:

• Lesen (r) ist 4
• Schreiben (w) ist 2
• Ausführen (x) ist 1

Diese Werte werden addiert. Eine 7 (4+2+1) sind also volle Rechte, eine 5 (4+0+1) bedeutet lesen und ausführen, aber nicht schreiben. Drei solcher Ziffern hintereinander ergeben die vollständige Angabe — eine je Klasse, in der Reihenfolge Besitzer, Gruppe, alle anderen.

Oktale Berechtigungsübersicht

• 0 = --- keine Rechte
• 1 = --x nur ausführen
• 2 = -w- nur schreiben
• 3 = -wx schreiben und ausführen
• 4 = r-- nur lesen
• 5 = r-x lesen und ausführen
• 6 = rw- lesen und schreiben
• 7 = rwx lesen, schreiben, ausführen

Eine Zeile aus ls -l lesen

Der Befehl ls -l zeigt die Rechte an. Eine Zeile sieht zum Beispiel so aus:

-rwxrwxr-x 1 benutzer gruppe 4096 Mai 20 12:34 beispiel.txt

Der erste Block besteht aus zehn Zeichen, und das erste davon ist kein Recht, sondern der Dateityp: - für eine normale Datei, d für ein Verzeichnis, l für einen Symlink. Welche Dateiarten es sonst noch gibt, behandelt unser Beitrag zu den wichtigsten Dateitypen unter Linux. Erst die folgenden neun Zeichen sind die Rechte, in drei Dreiergruppen für Besitzer, Gruppe und alle anderen.

Im Beispiel oben hat der Besitzer also rwx, die Gruppe ebenfalls rwx und alle anderen r-x — oktal ausgedrückt eine 775. Der Rest der Zeile: die Zahl der Hardlinks, der besitzende Benutzer, die besitzende Gruppe, die Grösse in Bytes, das Datum der letzten Änderung und der Dateiname.

chmod und chown in der Praxis

chmod ändert die Rechte, chown den Besitzer. Das sind zwei verschiedene Fragen: chmod legt fest, was erlaubt ist, chown legt fest, für wen die erste und die zweite Dreiergruppe überhaupt gelten.

chmod 755 beispiel.txt
ls -l beispiel.txt
-rwxr-xr-x 1 benutzer gruppe 4096 Mai 20 12:34 beispiel.txt

chmod 700 beispiel.txt
ls -l beispiel.txt
-rwx------ 1 benutzer gruppe 4096 Mai 20 12:34 beispiel.txt

Bei 755 hat der Besitzer volle Rechte, Gruppe und alle anderen dürfen lesen und ausführen. Bei 700 darf nur der Besitzer überhaupt etwas — Gruppe und Rest sehen die Datei zwar im Verzeichnis, kommen aber nicht hinein.

Den Besitzer setzt chown in der Form Besitzer:Gruppe, die Option -R wirkt rekursiv auf alles darunter:

sudo chown -R www-data:www-data /var/www/webpage

Warum chmod -R 755 auf ein Webverzeichnis ein Fehler ist

Hier stand früher der Rat, für eine WordPress-Installation einfach chmod -R 755 /var/www/webpage abzusetzen. Das ist bequem und falsch. Weil -R jede Datei gleich behandelt, bekommt damit auch jede einzelne Datei das Ausführungsrecht — jedes Bild, jede Konfigurationsdatei, jedes PHP-Skript. Verzeichnisse brauchen dieses Recht, Dateien in aller Regel nicht.

Die offizielle WordPress-Dokumentation trennt deshalb beides sauber und nennt genau diese zwei Befehle: 755 für Verzeichnisse, 644 für Dateien.

find /var/www/webpage/ -type d -exec chmod 755 {} \;
find /var/www/webpage/ -type f -exec chmod 644 {} \;

Kürzer geht es mit dem grossen X im symbolischen Modus. Es setzt das Ausführungsrecht nur dort, wo es sich um ein Verzeichnis handelt oder wo bereits eines gesetzt war:

chmod -R a=rX,u+w /var/www/webpage

umask und die Sonderbits

Zwei Dinge fehlten in der bisherigen Fassung, obwohl sie im Alltag ständig mitwirken.

Die umask ist die Maske, die bestimmt, welche Rechte eine neu angelegte Datei nicht bekommt. Der übliche Wert 0022 sorgt dafür, dass neue Dateien als 644 und neue Verzeichnisse als 755 entstehen. Wer sich wundert, warum eine frisch erzeugte Datei nicht ausführbar ist, hat hier die Antwort — und den aktuellen Wert liefert der Befehl umask ohne weitere Angaben.

Dazu kommen drei Sonderbits, die als vierte Ziffer vorangestellt werden und in der Ausgabe von ls -l als Buchstabe an der Stelle des x auftauchen:

• setuid (4) — das Programm läuft mit den Rechten seines Besitzers statt mit denen des Aufrufers. Sichtbar als -rwsr-xr-x.
• setgid (2) — dasselbe für die Gruppe. Auf ein Verzeichnis gesetzt, erben neue Dateien darin dessen Gruppe. Sichtbar als -rwxr-sr-x.
• Sticky Bit (1) — in einem für alle beschreibbaren Verzeichnis darf trotzdem nur löschen, wem die Datei gehört. Deshalb steht es auf /tmp, sichtbar als drwxrwxrwt.

Besonders setuid verdient Respekt: Ein Programm mit diesem Bit ist eine bewusst eingebaute Ausnahme vom Rechtemodell. Es gehört dorthin, wo es das Betriebssystem selbst gesetzt hat, und sonst nirgends.

Wenn etwas nicht klappt

Die drei Fälle, die in der Praxis am häufigsten für Ratlosigkeit sorgen:

• „Permission denied“, obwohl die Gruppe stimmt. Die Mitgliedschaft ist gesetzt, aber eure laufende Sitzung kennt sie noch nicht. Einmal ab- und wieder anmelden, dann mit id prüfen.
• Der Webserver liefert 403, obwohl die Datei lesbar ist. Dann fehlt das Ausführungsrecht an einem Verzeichnis im Pfad darüber. Prüfen lässt sich der ganze Pfad mit namei -l /var/www/webpage/index.php.
• Ein Skript startet nicht. Entweder fehlt das x, oder die Datei liegt auf einem Dateisystem, das mit der Option noexec eingehängt ist. Das zeigt mount | grep noexec.

Und die Regel, die am meisten Ärger erspart: Rechte werden enger gesetzt und bei Bedarf gelockert, nicht umgekehrt. chmod 777 löst jedes Rechteproblem und schafft dafür ein grösseres — es ist keine Lösung, sondern das Aufgeben.

Fazit: Berechtigungen sind die Grundlage der Sicherheit, nicht ihr Ersatz

Das Rechtemodell von Linux ist alt, einfach und erstaunlich tragfähig. Drei Rechte, drei Klassen, eine Zahl — mehr braucht es für neunzig Prozent der Fälle nicht. Wer es verstanden hat, verhindert damit einen grossen Teil der Fehler, die sonst als Sicherheitsproblem oder als kaputter Dienst wieder auftauchen.

Es hat aber auch klare Grenzen. Rechte regeln, wer zugreifen darf — nicht, was ein Programm tut, das legitim gestartet wurde. Dafür gibt es zusätzliche Schichten wie AppArmor, das wir im Beitrag zum Absichern des Firefox-Browsers in Aktion zeigen. Und sie schützen keine Daten, die jemand ausserhalb des laufenden Systems ausliest: Wer eine Festplatte ausbaut, liest sie mitsamt aller Rechteangaben — dagegen hilft nur Verschlüsselung, etwa mit LUKS. Wie weit das Rechtemodell als Schutz überhaupt trägt, ordnen wir ausserdem in Braucht Linux einen Virenschutz ein.

Falls ihr Fragen habt, schreibt sie in die Kommentare.

Quellen und weiterführende Links

• chmod(1) — oktale und symbolische Modi, das grosse X, Sonderbits und Sticky Bit
• chown(1) — Syntax Besitzer:Gruppe und die Option -R
• adduser(8) — „By default, each user is given a corresponding group with the same name“
• usermod(8) — warum -G ohne -a Gruppen entfernt
• userdel(8) — das Homeverzeichnis verschwindet nur mit -r
• sshd_config(5) — „By default, login is allowed for all groups“
• WordPress Hardening — 755 für Verzeichnisse, 644 für Dateien
• ubuntuusers-Wiki: Rechte — ausführliche deutschsprachige Gesamtdarstellung