Linux-Dateirechte auf dem Raspberry Pi verstehen & mit chmod/chgrp ändern (komplettes Anfänger-Tutorial)

Sven Krüger hat kommentiert und gefragt:

Erst einmal Danke für das Lob! Freut mich, dass du alle angeschaut hast und sie dir so gefallen 🙂

Deinen Themenvorschlag greife ich hiermit auf – Heute soll es um Datei- und Ordnerrechte unter Linux auf dem Raspberry Pi gehen: Wir schauen uns an, welche Rechte es gibt, wie du die konfigurierten Rechte anschauen aber auch ändern kannst. Zusätzlich gibt es einen kurzen Blick in die Geschichte, damit du auch verstehst, warum es so ist und auf welchen anderen Betriebssystemen die Rechte genau so verwaltet werden. Der Fokus liegt auf die Konsole, weil das am flexibelsten und am besten nachvollziehbar ist. Dennoch schauen wir uns am Schluss auch an, wie es über die grafische Oberfläche funktioniert.

Auf dem Raspberry Pi läuft in aller Regel eine Linux-Distribution. Meist ist das Raspberry Pi OS (ehemals Raspbian), wobei es – wie unter Linux üblich – nicht nur das eine Linux gibt. Sondern eine ganze Reihe an Distributionen, die sich auf verschiedene Anwendungsfälle fokussieren. Zum Beispiel RetroPi: Es baut auf Raspberry Pi OS auf und macht es besonders einfach, den Pi in einen Emulator für ältere Spiele zu verwandeln. Egal welche Distribution ihr verwendet: Linux stammt von Unix ab, die Dateirechte sind immer gleich. Es ist daher wichtig, diese zu verstehen. Dieser Beitrag ist aus diesem Grunde etwas länger. Ich empfehle, ihn komplett anzuschauen. Falls du das nicht möchtest oder einzelne Aspekte bereits kennst, kannst du die Überschriften bzw. Kapitel benutzen um zu springen. Die klickbaren Zeitstempel findest du beim Video zudem unten in der Beschreibung.

Ein kurzer Ausflug in die Geschichte von Linux und Unix

Unix entstand Ende der 1960er Jahre als eines der ersten Systeme, die man als Betriebssystem im heutigen Sinne bezeichnen kann. Es enthielt einige Funktionen, die für damalige Verhältnisse neu bis revolutionär waren: Unter anderem ermöglichte es, mehrere Benutzer am gleichen Computer arbeiten zu lassen. Dadurch entstand die Notwendigkeit von Berechtigungen, um Dateien vor unbefugtem Zugriff zu schützen.

Bis dahin handelte es sich bei Unix um ein freies, quelloffenes System. Doch Anfang der 1980er Jahre wurde es vom Telekommunikationskonzern AT&T kommerzialisiert. Fortan musste man hohe Lizenzgebühren bezahlen. Es folgten zahlreiche Unix-Derivate als freie Abspaltungen. Viele von Universitäten, wo Unix an Verbreitung gewann. Oft waren diese von Unix abstammenden Betriebssysteme nur teilweise oder gar nicht untereinander kompatibel. Um das Chaos zu Ordnen, entstand ab 1985 der POSIX-Standard.

Linux entstand Anfang der 1990er und ist weitgehendst POSIX-Kompatibel. Die Berechtigungen, die wir uns im folgenden anschauen, stammen im Kern also aus der Unix-Zeit. MacOS bzw. OS-X basieren auf BSD, was wiederum auf Unix basiert. Diese Betriebssysteme gelten eben so wie Linux als Unix-Ähnlich.

Berechtigungen unter Linux einsehen und verstehen

Wie sehe ich die Rechte und welche Rollen gibt es?

Wir springen wieder nach Vorne ins Jahre 2021 auf den Raspberry Pi: Welche Berechtigungen für Ordner und Dateien gesetzt sind, sehen wir auf der Konsole am einfachsten mit dem Werkzeug ls, es listet den Inhalt eines Ordners auf. Mit dem Schalter -l zeigt es uns dabei die wichtigsten Berechtigungen an. Zur Demonstration habe ich einen Ordner namens demo mit etwas Beispielinhalt erzeugt:

pi@testpi:~/demo $ ls -l
insgesamt 16
-rw-r--r-- 1 pi   pi     51 Okt  5 12:58 hallo.sh
drwxr-xr-x 2 pi   pi   4096 Okt  5 12:57 ordner1
drwxr-xr-x 2 root root 4096 Okt  5 12:57 ordner2
lrwxrwxrwx 1 pi   pi      8 Okt  5 12:59 pi-home -> /home/pi
-rw-r--r-- 1 pi   pi     37 Okt  5 12:58 skript.php

Man kann entweder mit cd in den Ordner navigieren, so wie ich das hier gemacht habe. Oder den Pfad als Argument angeben. Den Inhalt des Tem-Ordners erhalten wir etwa auch mit ls -l /tmp. Wichtig für die Berechtigungen sind die ersten vier Spalten. Um diese zu verstehen, müssen wir uns zunächst anschauen, wie das Berechtigungskonzept unter Linux grundsätzlich funktioniert: Alles wird wie eine Datei behandelt. Ein Ordner beispielsweise ist ebenfalls eine Datei, aber mit einem speziellen Attribut, dass ihn als Ordner kennzeichnet. Wenn ich mich im folgenden auf Dateien beziehe, sind damit also ebenfalls Ordner gemeint.

Zur Vergabe von Berechtigungen gibt es unter unixoiden Betriebssystemen und damit auch Linux drei Rollen oder Kategorien:

Der Nutzer als Eigentümer. Im Regelfall ist das jener Benutzer, der eine Datei angelegt hat. Jede Datei kann nur einem Benutzer gehören.
Eine Gruppe als Eigentümer. Zwar kann jede Datei auch nur einer Gruppe gehören, aber eine Gruppe kann unendlich viele Mitglieder haben. Darüber lässt sich mehreren Benutzern Zugriff auf eine Datei gewähren.
Alle anderen – Jeder Benutzer der weder (Nutzer-) Eigentümer ist, noch in der Eigentümer-Gruppe Mitglied ist, erhält diese Rechte.

Was für das Verständnis an vielen Stellen, an denen ihr Berechtigungen braucht, noch wichtig ist: Ein Benutzer muss kein Mensch sein. Natürlich kann das eine physische Person sein. Wenn ihr z.B. einen Computer zusammen mit einem Geschwisterteil nutzt, macht es Sinn, für jeden ein Benutzerkonto zu erstellen. Es gibt aber auch Systembenutzer, die gerade auf Servern oft eingesetzt werden: Etwa für ein Programm, dass unter diesem Benutzerkonto gestartet wird. Das ist vor allem sicherheitstechnisch sinnvoll und daher üblich.

Ein bekanntes Beispiel ist der Apache2 Webserver: Er läuft großteils über den Benutzer www-data. Daher habt ihr in unserem Beitrag zur Installation von Apache2 mit PHP und vielleicht auch in anderen Anleitungen schon gesehen, wie wir mit diesem Benutzer arbeiten.

Wem gehört eine Datei? Wie setze ich einen Benutzer und eine Gruppe als Eigentümer?

Der Befehl ls -l zeigt in der dritten Spalte von Links den Benutzer an, dem die Datei gehört. Direkt daneben befindet sich die Eigentümer-Gruppe. Warum steht hier in beiden Spalten pi? Das liegt daran, dass viele Distributionen – darunter auch Raspberry Pi OS – beim Anlegen eines Benutzers automatisch eine Gruppe erzeugen, die gleich heißt. Es gibt also einen Benutzer mit dem Name pi und eine gleichnamige Gruppe.

Schauen wir uns zunächst den Eigentümer-Benutzer an. Um diesen zu ändern, müssen wir root benutzen, etwa mit sudo. Selbst als Eigentümer darf ein normaler Benutzer niemand anders zum Eigentümer ernennen. Der root-Benutzer hat höchste Rechte und kann sich daher über alle Berechtigungen hinweg setzen. Für ihn greift auch die Berechtigung nicht, die für „alle anderen“ gesetzt ist. Damit wird klar, warum der root-Benutzer so sensibel ist und mit Bedacht genutzt werden sollte.

In diesem Beispiel habe ich zwei Benutzer: Einmal den Standardnutzer pi und einen selbst angelegten namens ulabs. Der ulabs Nutzer soll neuer Eigentümer von skript.php werden. Schauen wir uns zunächst an, wer derzeitiger Eigentümer ist:

ls -lh skript.php
-rw-r--r-- 1 pi pi 37 Okt  5 12:58 skript.php

Um den Eigentümer-Benutzer zu wechseln, wird der Befehl chown genutzt. Merkhilfe: chown ist die Abkürzung für change owner, also Besitzer ändern. Es folgt der Name der Gruppe und die Datei:

sudo chown ulabs skript.php 
ls -l skript.php 
-rw-r--r-- 1 ulabs pi 37 Okt  5 12:58 skript.php

Nun ist der Benutzer ulabs neuer Eigentümer. Weiterhin aber auch noch die Gruppe pi. Um die Gruppe ebenfalls zu ändern, gibt es den Befehl chgrp. Wie chown steht dies für change group, also Gruppe ändern. Der weitere Aufruf ist identisch:

$ sudo chgrp ulabs skript.php 
$ ls -l skript.php 
-rw-r--r-- 1 ulabs ulabs 37 Okt  5 12:58 skript.php

Mit den beiden Befehlen könnt ihr den Eigentümer-Nutzer von der Gruppe getrennt ändern. Beides gleichzeitig geht aber auch mit dem Befehl chown, in dem man Benutzer und Gruppe mit einem Doppelpunkt trennt. Folgendes Beispiel ändert den Besitzer-Benutzer auf pi und die Gruppe auf ulabs:

$ sudo chown pi:ulabs skript.php 
$ ls -l skript.php 
-rw-r--r-- 1 pi ulabs 37 Okt  5 17:55 skript.php

Wenn ihr mit Ordnern statt Dateien arbeitet, ist eine Besonderheit zu beachten: Die Rechte des Ordners werden beim ändern NICHT automatisch an die Dateien vererbt! Beispiel: Wir haben einen Ordner namens ordner1 mit einer Datei datei.sh. Beide gehören dem Benutzer pi sowie der Gruppe pi. Ändern wir die Gruppen-Eigentümerschaft auf ulabs, greift dies zwar für den Ordner. Die Datei darin gehört aber nach wie vor der Gruppe pi:

$ sudo chgrp ulabs ordner1
$ ls -l | grep ordner1
drwxr-xr-x 2 pi   ulabs 4096 Okt  5 14:25 ordner1
$ ls -l ordner1
-rw-r--r-- 1 pi pi 0 Okt  5 14:25 datei.sh

Möchtet ihr die Änderung für den Ordner inklusive aller Unterordner und Dateien anwenden, wird der Schalter -R benötigt. Er steht für Rekursion, d.H. auf alles anwenden was sich in diesem Ordner befindet. Rekursion ist mit Vorsicht anzuwenden! Beides gilt auch für chown.

$ sudo chgrp ulabs ordner1 -R
$ ls -l ordner1
-rw-r--r-- 1 pi ulabs 0 Okt  5 14:25 datei.sh

Welche Berechtigungen gibt es für die Rollen/Kategorien und wo sieht man diese?

Auf die drei Rollen (also Benutzer und Gruppe als Eigentümer sowie gebündelt allen anderen Benutzern) können wir nun Rechte vergeben, von denen es drei gibt. Die Rechte lassen sich in zwei Schreibweisen festlegen. Beginnen wir mit der lesbaren Variante: Buchstaben.

Berechtigung	Buchstabe	Zahl (Oktal)
Keine		0
Lesen	r (read)	4
Schreiben	w (write)	2
Ausführen	x (execute)	1

Lesen bedeutet, ich kann eine Datei öffnen (z.B. den Inhalt einer Textdatei einsehen) aber nicht verändern. Für Veränderungen werden Schreibrechte benötigt. Das Ausführen ist eine Besonderheit von Linux bzw. Unix, die vor allem Windows-Nutzer nicht kennen: Standardmäßig ist ein Binärprogramm (unter Windows eine .exe Datei) unter Linux aus Sicherheitsgründen nicht ausführbar. Dies ist nur möglich, wenn die „Ausführen“ Berechtigung gesetzt ist.

Jede Rolle bzw. Kategorie kann eines oder alle vier dieser Rechte besitzen. Welche Rechte aktuell gesetzt sind, sieht man in der ersten Spalte von ls -l:

-rw-r--r-- 1 pi   ulabs   37 Okt  5 12:58 skript.php

-rw-r–r– gibt alle Berechtigungen gebündelt an. Der erste Buchstabe zeigt, um welche Art von Datei es sich handelt. Ein Minus – steht für eine normale Datei. Bei Ordnern steht hier d für directory. Hier sieht man deutlich die Alles ist eine Datei Philosophie: Nur dieses eine Flag unterscheidet Dateien und Ordner. Neben l (symbolic link) für Verweise auf Dateien gibt es noch ein paar speziellere Arten wie u.a. b für block devices oder s für sockets. Für den Anfang reicht es zu wissen: Minus heißt Datei, d Ordner und l ist eine Verknüpfung.

Nun folgen drei Blöcke mit jeweils drei Buchstaben für den Eigentümer-Besitzer, die Eigentümer-Gruppe und alle anderen. Das Format ist immer rwx. Ist eine Berechtigung nicht aktiv, wird sie durch ein Minus ersetzt. Im Beispiel heißt das: Der Eigentümer-Besitzer darf Lesen (r) und Schreiben (w), Ausführen ist nicht erlaubt. Die Eigentümer-Gruppe darf nur lesen, ansonsten nichts. Das gleiche gilt für alle anderen.

Ändern lassen sich die Rechte mit dem Werkzeug chmod. Es steht für change mod, wobei mit mod die Dateirechte gemeint sind. Bevor wir Beginnen, ein wichtiger Hinweis: Außerhalb eures Home-Verzeichnisses und /tmp solltet ihr die Rechte von Dateien und vor allem von ganzen Ordnern nur dann ändern, wenn ihr versteht was ihr tut! Führt nicht einfach irgendwelche Befehle aus dem Internet aus. Eine gute Anleitung erklärt euch nicht nur was ihr da tut, sondern auch warum und zeigt im besten Falle sogar Alternativen auf. Das unbedachte setzen von Dateirechten kann verschiedene Probleme wie z.B. Sicherheitslücken erzeugen, vor allem in Kombination mit Diensten, die nach außen hin erreichbar sind. Zum ausprobieren am besten einen Ordner in eurem Home-Verzeichnis anlegen oder in /tmp, dort könnt ihr recht gefahrlos experimentieren.

Der Aufruf von chmod geschieht nach folgendem Muster:

chmod <modus> datei

Beim Modus müssen wir zunächst die Rolle bzw. Kategorie angeben, sie werden jeweils mit dem Anfangsbuchstabe abgekürzt:

u für den Eigentümer-Benutzer (user)
g für die Eigentümer-Gruppe (group)
o für others, also alle anderen Benutzer

Danach folgt ein Plus (+) um Rechte hinzuzufügen, oder ein Minus (-) zum entfernen. Schlussendlich noch das gewünschte Recht: r für Lesen, w für Schreiben und x für das Execute-Bit, damit die Datei ausgeführt werden kann.

Beispiel: Das skript.php von kann nur vom Eigentümer-Benutzer geschrieben werden, nicht aber von der Eigentümer-Gruppe. Um das zu ändern, führen wir folgenden chmod Befehl aus:

$ chmod g+w skript.php
$ ls -l skript.php 
-rw-rw-r-- 1 pi ulabs 37 Okt  5 12:58 skript.php

Aus -rw-r ist -rw-rw geworden. Mit g-w könnten wir das Recht wieder entfernen. Sollen mehrere Rechte auf einmal gesetzt bzw. entfernt werden, trennt man diese mit Komma:

chmod g-w,o-r skript.php
$ ls -l skript.php 
-rw-r----- 1 pi ulabs 37 Okt  5 12:58 skript.php

Der Eigentümer-Gruppe haben wir mit g-w das Schreibrecht entzogen, eben so wie allen anderen Benutzern mit o-r (o = other). Dadurch kann der Eigentümer-Benutzer Lesen und Schreiben, die Eigentümer-Gruppe Lesen, alle anderen dürfen nichts machen. Für ganze Ordner müssen wir den rekursiven Modus mit -R verwenden. Wie bei chgrp zuvor schon erwähnt, sollte auch das mit Bedacht genutzt werden – wie generell jegliche Rekursion.

Während sich die + und – Operatoren gut eignen, um bestehende Berechtigungen anzupassen, möchte man diese vielleicht auch einfach überschreiben. Beispielsweise in einem Skript, welches sicherstellt, dass die Berechtigungen 1:1 wie definiert umgesetzt sind. Dazu einfach ein Istgleich-Zeichen (=) benutzen:

chmod u=rwx,g=r skript.php

Wird eine Kategorie bzw. Rolle nicht angegeben, erhält sie keinerlei Rechte. In diesem Beispiel darf der Eigentümer-Benutzer alles (also Lesen, Schreiben und Ausführen). Die Eigentümer-Gruppe nur lesen und alle anderen dürfen nicht darauf zugreifen.

Was hat es mit den Nummern auf sich?

Ihr habt vielleicht in Anleitungen schon einmal Berechtigungen mit Nummern gesehen, beispielsweise chmod 660, 777 oder andere Zahlenwerte. Man kann alle gezeigten Rechte auch oktal abbilden, also mit Ziffern von 0 bis 7. Schauen wir uns mal das oktale System am Beispiel von 660 an. Es kann eine führende Null besitzen, etwa 0660, das ist an dieser Stelle irrelevant. Jede Ziffer steht wieder für eine Kategorie bzw. Rolle, in der gleichen Reihenfolge wie bei den Buchstaben: Erste 6 für den Eigentümer-Benutzer, die zweite für die Eigentümer-Gruppe und die Dritte für alle anderen.

In der Tabelle oben wurde schon kurz erwähnt, dass 1 für Ausführen, 2 für Schreiben und 4 für Leserechte steht. Möchte man mehrere Rechte gewähren, addiert man einfach die Zahlen. 6 steht somit für Lesen (4) + Schreiben (2). Folgende Befehle erzeugen daher die gleichen Rechte:

chmod u=rw,g=rw,o= skript.php
chmod 660 skript.php

In beiden Fällen dürfen Eigentümer-Nutzer und Gruppe sowohl Lesen als auch Schreiben, der Rest hat keinerlei Rechte. Möchten wir allen anderen Benutzern Leserechte gewähren, müsste die 0 durch eine 4 ersetzt werden bzw. o=r zur anderen Schreibweise hinzugefügt:

chmod u=rw,g=rw,o=r skript.php
chmod 664 skript.php

# Kontrolle
$ ls -l skript.php 
-rw-rw-r-- 1 pi ulabs 37 Okt  5 12:58 skript.php

Der wesentliche Unterschied liegt darin, dass man bei der oktalen Schreibweise weniger Tippen muss. Einige erfahrenere Linux-Nutzer bevorzugen sie daher. Für Anfänger würde ich dagegen die Buchstaben empfehlen, weil sie lesbarer und ohne Vorwissen logischer sind. Hat man das Konzept einmal verstanden, ist das herleiten von u=rw,g=rw einfacher statt sich zu überlegen bzw. nachschlagen zu müssen, wofür die 6 noch mal stand. Letztendlich kann man beide Wege nutzen und erhält die gleichen Berechtigungen.

Was ist das sogenannte „Sticky Bit“?

Zuvor hatten wir kurz über die führende Null gesprochen, etwa 0600 statt 600. Dahinter verbirgt sich das sogenannte „Sticky Bit“: Früher diente es dazu, um ausführbare Dateien automatisch in den Swap, also die Auslagerungsdatei, zu kopieren. Dadurch beschleunigte sich der nächste Start des Programmes. Heutzutage hat das durch bessere Hardware und modernere Optimierungen in Linux kaum mehr Relevanz für die Leistung.

Anders verhält es sich bei Ordnern: Dort bewirkt es, dass man nur Dateien ändern und löschen darf, die der Benutzer selbst angelegt hat. Das ist zum Beispiel in /tmp sinnvoll: Dort darf standardmäßig jeder Nutzer schreiben und ausführen – aber er soll nicht die Daten anderer Programme/Benutzer verändern können.

pi@testpi:~ $ touch /tmp/pi-test
ulabs@testpi:~ $ rm -f /tmp/pi-test
rm: das Entfernen von '/tmp/pi-test' ist nicht möglich: Die Operation ist nicht erlaubt

Man erkennt es am Buchstabe „t“, der am Ende der Berechtigungen steht, falls das Sticky-Bit aktiv ist:

$ ls -l / | grep tmp
drwxrwxrwt  16 root root  4096 Okt  5 17:02 tmp

Um es zu setzen, fügt man zur 3-Stelligen Berechtigung (z.B. 660) vorne die Ziffer „eins“ an: 1660 aktiviert das Sticky-Bit, 0660 deaktiviert es. Standardmäßig lässt man die vierte Ziffer weg, wodurch es deaktiviert ist. Im Alltag benötigt man das Sticky-Bit eher selten, ich wollte es der Vollständigkeit halber dennoch kurz aufzeigen.

Wie kann ich mehrere Benutzer auf eine Datei bzw. einen Ordner berechtigen?

Zuvor hatte ich bei den Kategorien bzw. Rollen darauf hingewiesen, dass es nur einen Nutzer als Eigentümer geben darf. So sehen es die ursprünglichen Unix-Rechte vor. Es gibt mit ACLs (also Access Control Lists) eine Möglichkeit, die Beschränkung auf einen Benutzer bzw. eine Gruppe zu umgehen. Damit sind feinere Berechtigungen möglich. Aber: Das erhöht die Komplexität und Fehleranfälligkeit. Wirklich brauchen tut man es zudem nur in wenigen Ausnahmefällen. Meist auf Systemen mit sehr vielen Benutzern oder in bestimmten Softwarekonstellationen.

Für Anfänger ist dies nicht zu empfehlen, weswegen ich an dieser Stelle nicht weiter darauf eingehe. Vieles lässt sich mit dem gezeigten Konzept aus Benutzer und Gruppe als Eigentümer abbilden. Das würde ich auch bevorzugt nutzen. Um mehreren Benutzer Zugriff zu gewähren, reicht oft eine Gruppe, in die man diese Nutzer aufnimmt. Wenn euch erweiterte ACLs dennoch interessieren, schreibt es gerne in die Kommentare – eventuell greifen wir das in Zukunft in einem eigenen Beitrag auf.

Verwaltung der Rechte über eine grafische Oberfläche

Habt ihr auf dem Pi eine grafische Desktop-Umgebung installiert, kann man die Berechtigungen auch dort einsehen sowie teilweise ändern: Dazu navigiert ihr im Dateiexplorer zur gewünschten Datei, dann Rechtsklick > Eigenschaften. Im Reiter Berechtigungen sehr ihr den Eigentümer-Besitzer sowie die Gruppe. Beides lässt sich hier jedoch nicht ändern, da die grafische Oberfläche (aus gutem Grund) im Kontext des Benutzers läuft, anstelle von root.

Die Zugriffsrechte kann man hingegen ändern, sofern der angemeldete Benutzer (Standardmäßig pi) Eigentümer ist. Im Home-Verzeichnis beispielsweise ist das in der Regel kein Problem. Bei systemweiten Konfigurationsdateien stoßen wir damit an Grenzen. Den Dateiexplorer mit root-Rechten zu starten, ist nicht zu empfehlen.

Ein weiterer Grund in meinen Augen, die Konsole tendenziell zu bevorzugen. Dort könnt ihr (entsprechende Rechte vorausgesetzt) alles uneingeschränkt ausführen. Außerdem seid ihr nicht auf eine grafische Oberfläche angewiesen: Die Konsolen-Varianten funktionieren auf einer Linux-Workstation mit Desktop-Umgebung eben so wie auf dem Pi oder jedem Linux-Server. Die Befehle lassen sich mit einem Bash-Skript auch einfach automatisieren sowie dokumentieren.

Warum sollte man sich die Mühe mit Benutzern, Gruppen und Berechtigungen machen? Es gibt doch chmod 777!

Immer wieder sieht man in verschiedenen Diskussionen und teils sogar Foren, man soll Berechtigungsprobleme doch einfach mit chmod 777 lösen – am besten noch rekursiv. Das ist viel einfacher und dann geht alles. Letzteres mag zwar oft stimmen, ist zeitgleich aber auch das Problem: 777 heißt jeder darf alles. Klar kann man das zum testen mal machen. Gerade in einer VM oder auf einem Testgerät ist das manchmal sogar hilfreich – denn dann kann man bei der Fehlersuche ausschließen, dass es irgendwo Berechtigungsprobleme gibt. Produktiv sollte an das aber besser nicht machen.

Zum einen wegen des bekannten Spruches Mit großer Macht geht auch große Verantwortung einher. Durch menschliche Fehler kann ein Programm oder man selbst versehentlich Dinge tun, die man nicht wollte. Wenn der Webserver problemlos die gesamte Root-Partition löschen kann, ist das System anschließend kaputt. Verweigert das System die Löschung von 90% davon, ist der Schaden zumindest deutlich geringer.

Und dann ist da noch das Thema Sicherheit. Spätestens wenn ihr mehrere Benutzer auf einem Pi oder anderem Linux-System habt, möchtet ihr denen sicher nicht Vollzugriff geben. Das ist ein unnötiges Risiko, wenn sie nur auf ein paar einzelne Ordner Zugreifen müssen.

Wir müssen uns zudem im klaren sein, dass praktisch jede Software Sicherheitslücken besitzt. Manche mehr, andere weniger. Die Auswirkungen sind ebenfalls unterschiedlich gravierend. Aber grundsätzlich sollten wir davon ausgehen, dass es welche gibt. Wenn eine Software alles darf, kann sie im Falle einer Sicherheitslücke auch auf alles zugreifen und sensible Daten zugreifen oder gar manipulieren, mit denen sie eigentlich nichts zutun hat. Im schlimmsten Falle ist das ein Totalschaden, der z.B. durch erbeutete Zugangsdaten von anderen Systemen noch gravierender wird, als auf den ersten Blick vermutet.

Eine elementare Grundregel für sichere Systeme ist daher: So viele Zugriffsrechte wie nötig, so wenig wie möglich. Das gilt um so mehr für Schnittstellen nach außen, beispielsweise einen Webserver – vor allem wenn dieser ins Internet erreichbar ist. Gerade bei so was muss einem klar sein: Das ist eine Schnittstelle ins Heimnetzwerk. Ein schlecht abgesicherter Pi kann das Einfallstor für ganz andere Geräte im Netzwerk sein, die vielleicht wesentlich sensiblere Daten beinhalten – aber das ist ein eigenes Thema.

Wichtig an dieser Stelle ist, dass chmod 777 schlechte Praxis darstellt! Stattdessen solltet ihr eure Berechtigungsstruktur entsprechend einrichten, dass der Nutzer bzw. die jeweilige Gruppe entsprechend jene Rechte bekommt, die tatsächlich gebraucht werden. Wie das geht, wisst ihr ja nun 🙂 Natürlich soll das nicht heißen, dass ihr nichts mehr ausprobiert. Es soll sensibilisieren, dass man zwischen Spielwiese und Produktivsystem trennt und sich spätestens beim produktiven System Gedanken um dessen Absicherung machen sollte, statt sich mit Methoden wie chmod 777 das Sicherheitskonzept zu zerschießen. Linux ist da nämlich ziemlich mächtig und restriktiv – die beste Festung nützt allerdings wenig, wenn der Besitzer dessen Hintereingang offen stehen lässt.