In einem Satz
chmod ist der Unix-Befehl, der festlegt, wer eine Datei lesen, beschreiben oder ausführen darf, und fungiert als das grundlegende System zur Zugriffskontrolle für die meisten Server und Entwicklerrechner der Welt.
Welches Problem es löst
Stell dir die Anfänge der Computerzeit vor: eine Person, eine Maschine, eine Aufgabe nach der anderen. In einem solchen System sind Dateiberechtigungen eine Lösung auf der Suche nach einem Problem. Wenn du die einzige Person bist, die den Computer jemals benutzen wird, vor wem schützt du dann die Dateien? Vor dir selbst?
Dann kam Unix in den späten 1960er Jahren bei Bell Labs. Seine revolutionäre Idee war es, von Grund auf ein Multi-User- und Multi-Tasking-Betriebssystem zu sein. Plötzlich waren mehrere Programmierer über verschiedene Terminals am selben Mainframe-Computer angemeldet und arbeiteten alle gleichzeitig. Das schuf ein neues und dringendes Problem: Wie hältst du Dennis davon ab, versehentlich (oder „versehentlich“) Kens neuen C-Compiler zu löschen? Wie erlaubst du deinem Projektpartner, deinen Code zu lesen, hinderst ihn aber daran, ihn zu ändern? Wie schützt du die zentralen Betriebssystemdateien vor einem tollpatschigen Praktikanten?
Die Lösung war ein bestechend einfaches und robustes System aus Eigentümerschaft und Berechtigungen, das direkt in das Dateisystem integriert wurde. Jede Datei und jedes Verzeichnis sollte einen Besitzer haben, zu einer Gruppe gehören und einen spezifischen Satz von Berechtigungen für drei Benutzerklassen haben: den Besitzer, die Mitglieder der Gruppe und alle anderen.
Der Befehl, um den „Modus“ einer Datei zu ändern – also diese Berechtigungen anzupassen – wurde chmod getauft. Er wurde zum universellen Werkzeug für Systemadministratoren und Benutzer, um zu erklären: „Diese Datei gehört mir, und hier sind die Regeln für den Umgang damit.“ Er löste das Multi-User-Chaos-Problem so effektiv, dass dasselbe Kernmodell heute noch auf praktisch jedem Linux-Server, macOS-Rechner, Android-Handy und IoT-Gerät auf diesem Planeten verwendet wird.
Wie es unter der Haube funktioniert
Im Kern ist das chmod-System ein 3x3-Raster aus Regeln, mit ein paar speziellen Flags für den extra Pfiff. Um es zu verstehen, musst du die drei Arten von Berechtigungen und die drei Benutzerklassen, auf die sie angewendet werden können, kennen.
Die drei Berechtigungen: Lesen, Schreiben, Ausführen
Alles dreht sich um drei grundlegende Aktionen, die du mit einer Datei oder einem Verzeichnis durchführen kannst. Sie werden durch die Buchstaben r, w und x dargestellt.
- Lesen (
r): Die Fähigkeit, den Inhalt einer Datei zu öffnen und anzusehen. - Schreiben (
w): Die Fähigkeit, den Inhalt einer Datei zu modifizieren, zu ändern oder zu löschen. - Ausführen (
x): Die Fähigkeit, die Datei als Programm oder Skript auszuführen.
Aber hier ist der erste Haken: Für ein Verzeichnis bedeuten diese Berechtigungen etwas leicht anderes. Das ist eine super häufige Quelle für Verwirrung.
| Berechtigung | Für eine Datei | Für ein Verzeichnis |
|---|---|---|
Lesen (r) |
Kann den Inhalt der Datei sehen | Kann die Namen der Dateien im Verzeichnis auflisten (ls) |
Schreiben (w) |
Kann den Inhalt der Datei ändern | Kann Dateien innerhalb des Verzeichnisses erstellen, umbenennen oder löschen |
Ausführen (x) |
Kann die Datei ausführen | Kann das Verzeichnis betreten (cd) und auf Dateien darin zugreifen |
Denk mal über den letzten Punkt nach. Wenn ein Verzeichnis für dich keine Ausführungsberechtigung hat, kannst du nicht hineinwechseln (cd), selbst wenn du seinen Inhalt sehen kannst! Du brauchst x, um durch die „Tür“ des Verzeichnisses zu gehen.
Die drei Benutzerklassen: Besitzer, Gruppe, Andere
Unix-Berechtigungen sind nicht universell; sie werden bestimmten Benutzerkategorien zugewiesen.
- Besitzer (
ufür "user"): Ein einzelner Benutzer, dem die Datei gehört. Typischerweise ist das die Person, die sie erstellt hat. Der Besitzer hat die meiste Kontrolle. - Gruppe (
g): Jede Datei gehört zu einer Gruppe. Dies ermöglicht es dem Besitzer, den Zugriff mit bestimmten Teammitgliedern zu teilen. Zum Beispiel könnten alle Dateien für „Projekt Apollo“ zur Gruppeapollo-devsgehören. - Andere (
ofür "others"): Buchstäblich alle anderen. Jeder Benutzer auf dem System, der nicht der Besitzer ist und nicht zur Gruppe der Datei gehört.
Wenn du eine Berechtigungszeichenfolge wie rwxr-xr-- siehst, sind das eigentlich drei Sätze von rwx-Berechtigungen, die für Besitzer, Gruppe und Andere (in dieser Reihenfolge) zusammengefügt sind.
rwx: Der Besitzer kann lesen, schreiben und ausführen.r-x: Die Gruppe kann lesen und ausführen, aber nicht schreiben.r--: Andere können nur lesen.
Die zwei Notationen: Symbolisch vs. Oktal
Es gibt zwei Möglichkeiten, chmod mitzuteilen, was du willst, und Entwickler übersetzen ständig zwischen ihnen.
1. Symbolische Notation (die „freundliche“ Art)
Die symbolische Notation verwendet die Buchstaben, die wir bereits gelernt haben (r, w, x und u, g, o, a, wobei a für „alle“ steht). Du verwendest +, um eine Berechtigung hinzuzufügen, -, um sie zu entfernen, und =, um sie exakt zu setzen.
# Dem Besitzer die Ausführungsberechtigung geben
$ chmod u+x mein_skript.sh
# Schreibberechtigung für die Gruppe und Andere entfernen
$ chmod go-w sensible_daten.txt
# Berechtigungen exakt setzen: Besitzer kann lesen/schreiben, Gruppe kann lesen, Andere haben keinen Zugriff
$ chmod u=rw,g=r,o= config.yml
Das ist super, um kleine, gezielte Änderungen vorzunehmen.
2. Oktale Notation (die „nerdige“ Art)
Oktal ist schneller, in Skripten gebräuchlicher und basiert auf dem Binärsystem. Jede Berechtigung (r, w, x) ist ein Bit in einer 3-Bit-Zahl.
r(Lesen) ist das erste Bit mit dem Wert 4.w(Schreiben) ist das zweite Bit mit dem Wert 2.x(Ausführen) ist das dritte Bit mit dem Wert 1.
Du addierst die Zahlen für die gewünschten Berechtigungen.
| Zahl | Binär (rwx) |
Erteilte Berechtigungen |
|---|---|---|
| 0 | 000 (---) |
Keine |
| 1 | 001 (--x) |
Ausführen |
| 2 | 010 (-w-) |
Schreiben |
| 3 | 011 (-wx) |
Schreiben und Ausführen |
| 4 | 100 (r--) |
Lesen |
| 5 | 101 (r-x) |
Lesen und Ausführen |
| 6 | 110 (rw-) |
Lesen und Schreiben |
| 7 | 111 (rwx) |
Lesen, Schreiben, Ausführen |
Ein dreistelliger Oktalcode wie 755 repräsentiert die Berechtigungen für Besitzer, Gruppe und Andere.
chmod 755 mein_skript.sh bedeutet:
- Besitzer:
7(rwx) - Lesen, schreiben und ausführen. - Gruppe:
5(r-x) - Lesen und ausführen. - Andere:
5(r-x) - Lesen und ausführen.
Dies ist eine sehr häufige Berechtigung für ausführbare Skripte, die auch von anderen sicher ausgeführt werden können. Eine übliche Berechtigung für eine Datei ist 644 (Besitzer kann lesen/schreiben, alle anderen können nur lesen).
Die Special Guests: SUID, SGID und das Sticky Bit
Über das grundlegende rwx hinaus gibt es drei spezielle Modi, die durch eine vierte Oktalziffer am Anfang dargestellt werden (z. B. chmod 4755).
- SUID (Set User ID) - Oktal
4: Wenn eine ausführbare Datei mit diesem Bit ausgeführt wird, läuft sie mit den Rechten des Dateibesitzers, nicht des Benutzers, der sie gestartet hat. Das klassische Beispiel ist derpasswd-Befehl, der die geschützte/etc/shadow-Datei ändern muss. Diepasswd-Anwendung gehörtrootund hat das SUID-Bit gesetzt. Wenn also ein normaler Benutzer sie ausführt, erhält sie vorübergehend Root-Rechte nur für diese eine Operation. Mächtig, aber gefährlich. - SGID (Set Group ID) - Oktal
2: Ähnlich wie SUID, aber ein Programm läuft mit der Gruppen-Identität der Datei. Nützlicher ist, wenn es auf ein Verzeichnis gesetzt wird: Jede neue Datei oder jedes neue Verzeichnis, das darin erstellt wird, erbt automatisch die Gruppe des übergeordneten Verzeichnisses, nicht die primäre Gruppe des erstellenden Benutzers. Dies ist unerlässlich für gemeinsam genutzte Projektordner. - Sticky Bit - Oktal
1: Dies hat eine seltsame Geschichte, aber heute wird es fast ausschließlich für Verzeichnisse verwendet. Wenn ein Verzeichnis das Sticky Bit hat (wie der Systemordner/tmp), können alle Benutzer Dateien darin erstellen, aber ein Benutzer kann nur die Dateien löschen oder umbenennen, die ihm selbst gehören. Es verhindert, dass Leute in einem gemeinsam genutzten Bereich an den Sachen der anderen herumpfuschen.
Geschichten aus der Praxis
Der Fall des nicht ausführbaren Skripts
Ein junger Entwickler, Alex, schreibt ein geniales Shell-Skript, um das Server-Deployment zu automatisieren. Er committet deploy.sh nach Git. Auf dem Produktionsserver klont er das Repository, tippt ./deploy.sh und drückt Enter. Die Antwort: bash: ./deploy.sh: Permission denied. Panik. Hat er den Server kaputt gemacht? Ein erfahrener Entwickler tippt ruhig ls -l deploy.sh und zeigt ihm die Ausgabe: -rw-r--r--. Die Datei hatte Lese- und Schreibberechtigungen, aber keine Ausführungsberechtigung (x). Git erhält die Ausführungsberechte nicht standardmäßig. Ein schnelles chmod +x deploy.sh später lief das Skript perfekt.
Lektion: Dateien, insbesondere aus Quellen wie Git oder ZIP-Archiven, sind standardmäßig nicht ausführbar. Du musst explizit die Erlaubnis erteilen, sie auszuführen.
Der Albtraum mit dem geteilten Projektordner
Ein Design-Team und ein Entwickler-Team mussten Assets in einem Ordner auf einem Linux-Server teilen: /data/project-x. Der Sysadmin steckte alle in die Gruppe project-x-team und gab der Gruppe Schreibzugriff auf den Ordner. Aber es herrschte Chaos. Wenn ein Designer eine Datei hochlud, gehörte sie designer:designers, und die Entwickler konnten sie nicht ändern. Wenn ein Entwickler einen Unterordner erstellte, gehörte er dev:developers, und die Designer konnten keine Dateien hinzufügen. Alle baten ständig den Sysadmin, die Berechtigungen zu korrigieren. Die Lösung? Der Admin führte chmod g+s /data/project-x aus. Dadurch wurde das SGID-Bit für das Verzeichnis gesetzt. Von da an erbte jede neue Datei und jeder neue Ordner, der in /data/project-x erstellt wurde, automatisch die Gruppe project-x-team. Die Harmonie war wiederhergestellt.
Lektion: SGID auf einem Verzeichnis ist der korrekte, saubere Weg, um gemeinsam genutzte Gruppenordner zu verwalten.
Die Sicherheitslücke auf der öffentlichen Website
Ein freiberuflicher Webentwickler startete eine einfache PHP-Website für einen Kunden. Der Einfachheit halber ließ er die Datenbank-Konfigurationsdatei config.inc.php im selben Verzeichnis wie die Startseite. Die Datei enthielt den Datenbank-Benutzernamen und das Passwort im Klartext. Ihre Berechtigungen waren die standardmäßigen 644 (-rw-r--r--), was bedeutete, dass der Benutzer des Webservers sie lesen konnte (gut), aber auch jeder auf der Welt, der die URL erraten hat. Ein Sicherheitsscanner fand die Datei, und ein Angreifer lud die Datenbank-Zugangsdaten herunter. Die Lösung wäre chmod 600 config.inc.php gewesen, was die Datei nur für den Besitzer (den Webserver-Prozess) lesbar macht.
Lektion: Gehe niemals davon aus, dass Standardberechtigungen sicher sind. Sensible Dateien wie Konfigurationen und private Schlüssel sollten so restriktiv wie möglich gesperrt werden.
Häufige Fehler und Fallen
- Der
chmod 777-Vorschlaghammer. Wenn frustriert, sind viele versucht,chmod -R 777 .auf ein Verzeichnis anzuwenden. Dies gibt rekursiv jedem die Erlaubnis, alles zu lesen, zu schreiben und auszuführen. Es ist eine katastrophale Sicherheitslücke und das digitale Äquivalent dazu, die Türen deines Hauses auszuhängen und ein Schild mit „Gratis-Zeug hier drin“ auf den Rasen zu stellen. Tu es nicht. - Das
x-Recht für Verzeichnisse vergessen. Du kannstr-Berechtigung für eine Datei haben, aber nicht darauf zugreifen können, weil du keinex-Berechtigung für eines der übergeordneten Verzeichnisse in ihrem Pfad hast. Du benötigst die Ausführungsberechtigung für alle Verzeichnisse, die du durchqueren möchtest. - Das
umask-Mysterium. Hast du dich jemals gefragt, warum neue Dateien, die du erstellst,644und nicht777sind? Das ist deineumaskbei der Arbeit. Eineumaskist eine „Maske“, die deine Shell anwendet und die Berechtigungen von Dateien und Verzeichnissen entfernt, während sie erstellt werden. Eine üblicheumaskvon022entfernt die „Schreib“-Berechtigung für Gruppe und Andere und macht aus einem Standard-666ein644. - Denken,
chmod +xsei dasselbe wiechmod 755. Ist es nicht.chmod 755 meine_dateisetzt die Berechtigungen absolut.chmod +x meine_dateifügt das Ausführungs-Bit für jede Benutzerklasse (Besitzer, Gruppe, Andere) hinzu, die bereits das Lese-Bit hat, ohne andere Bits zu ändern. Der symbolische Modus ist relativ; der oktale Modus ist absolut.
Warum du es auf dem Schirm haben solltest
Wenn du jemals eine nicht-Windows Kommandozeile anfasst, musst du chmod verstehen. Das ist nicht optional. Dieses Wissen ist entscheidend, wenn du:
- Eine Anwendung auf einem Linux-Server bereitstellst.
- Skripte schreibst (Shell, Python, Node.js), die ausgeführt werden müssen.
- Mit Git arbeitest, das seine eigenen Vorstellungen von Dateiberechtigungen hat.
- Dateifreigaben oder kollaborative Umgebungen einrichtest.
- Die Sicherheit eines Servers durch Einschränkung des Zugriffs auf sensible Dateien härtest.
- Docker verwendest, wo Dateiberechtigungen innerhalb des Containers von größter Bedeutung sind.
chmod ist einer der ersten und grundlegendsten Befehle, der einen gelegentlichen Benutzer von einem echten Systembetreuer oder Entwickler unterscheidet. Es zu verstehen ist ein Initiationsritus, um die Maschine zu kontrollieren, anstatt sie nur zu benutzen.
Tauche tiefer ein
- Wikipedia: chmod - Ein großartiger Überblick über den Befehl, seine Geschichte und seine verschiedenen Notationen.
- Wikipedia: Dateisystem-Berechtigungen - Ein breiterer Blick auf die Konzepte von DAC, ACLs und die symbolische/oktale Notation über Systeme hinweg (Englisch).
- The Linux man-pages project: chmod(1) - Die kanonische, technische Referenz für den
chmod-Befehl unter Linux. Detailliert, aber maßgeblich. - The Open Group Base Specifications (POSIX): chmod - Der eigentliche Standard, der definiert, wie sich
chmodauf jedem POSIX-konformen System (wie macOS und Linux) verhalten muss. - ArchWiki: File permissions and attributes - Ein sehr praktischer und gut gepflegter Guide aus der Arch Linux Community, der
chmod,chownund spezielle Attribute abdeckt (Englisch).