Linux-Benutzer, Gruppen & Dateirechte verstehen

Fast jede „Permission denied“-Meldung, jeder falsch startende Container und jede unsichere Konfiguration hat dieselbe Wurzel: ein Missverständnis darüber, wer auf einem Linux-Server was darf. Dieser Guide räumt das ein für alle Mal auf – mit echten Befehlen statt Theorie.

Was bauen wir?

Diesmal keinen Dienst, sondern das Fundament, auf dem alle anderen Rezepte stehen: das Rechtemodell von Linux. Am Ende verstehst du, was ein Benutzer und eine Gruppe sind, wie du rwx-Rechte und die Zahlen wie 755 liest und setzt, warum www-data und docker als Gruppen ständig auftauchen – und wann sudo das richtige Werkzeug ist und wann nicht. Alle Beispiele sind auf Debian 13 ausgeführt und funktionieren auf jedem Linux-Server.

Voraussetzungen

• Ein Linux-Server mit Root- oder sudo-Zugang (dein netcup-VPS reicht)
• Vertrautheit mit den wichtigsten Terminal-Befehlen (ls, cd, cat)
• Kein zusätzliches Paket nötig – alle Werkzeuge sind Teil von Debian

Schritt für Schritt

Schritt 1: Wer bin ich? Benutzer und ihre IDs

Jeder Prozess und jede Datei gehört einem Benutzer. Wer du gerade bist, zeigt id:

id

uid=0(root) gid=0(root) groups=0(root)

Drei Dinge stehen hier: die UID (User-ID, 0 = root, der Administrator), die primäre GID (Group-ID) und alle Gruppen, in denen du Mitglied bist. Menschliche Benutzer bekommen auf Debian UIDs ab 1000, darunter liegen Systembenutzer für Dienste.

Benutzer sind in /etc/passwd hinterlegt – eine schlichte Textdatei:

grep -E '^(root|www-data|nobody):' /etc/passwd

root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Die Felder sind Name, Passwort-Platzhalter (x = das echte Hash steht in /etc/shadow), UID, GID, Kommentar, Home-Verzeichnis und Login-Shell. Wichtig: www-data – der Benutzer, unter dem Webserver laufen – hat als Shell /usr/sbin/nologin. Solche Dienstbenutzer können sich absichtlich nicht einloggen; sie existieren nur, damit ein Prozess mit minimalen Rechten läuft statt als root.

Schritt 2: Einen Benutzer anlegen

Für alles außer der Erstkonfiguration solltest du nicht als root arbeiten. Lege einen normalen Benutzer an – hier koch:

useradd -m -s /bin/bash koch

-m erstellt das Home-Verzeichnis /home/koch, -s /bin/bash setzt die Login-Shell. Ein Passwort vergibst du mit passwd koch. Prüfe das Ergebnis:

id koch

uid=1000(koch) gid=1000(koch) groups=1000(koch)

useradd hat automatisch eine gleichnamige primäre Gruppe koch (GID 1000) angelegt. Das ist der Debian-Standard: Jeder Benutzer bekommt seine eigene Gruppe – so ist eine neue Datei nie versehentlich für andere lesbar, nur weil sie eine gemeinsame Gruppe teilen.

Schritt 3: Rechte lesen – das rwx-Modell

Jede Datei kennt drei Rechte-Sätze: für den Besitzer, für die Gruppe und für alle anderen. Sieh sie dir mit ls -l an:

ls -l

-rw-r--r-- 1 root root  0 Jul 24 19:02 datei.txt
drwxr-xr-x 2 root root 40 Jul 24 19:02 ordner

Die erste Spalte ist der Schlüssel. Zerlege drwxr-xr-x:

• Zeichen 1 – der Typ: - Datei, d Verzeichnis, l symbolischer Link.
• Zeichen 2–4 (rwx) – Rechte des Besitzers: lesen (r), schreiben (w), ausführen (x).
• Zeichen 5–7 (r-x) – Rechte der Gruppe.
• Zeichen 8–10 (r-x) – Rechte aller anderen.

Danach folgen Besitzer (root) und Gruppe (root). Bei datei.txt darf also nur root schreiben, alle dürfen lesen.

Schritt 4: Rechte als Zahl – warum 755 und 644

Dieselben Rechte schreibt man kompakt als Oktalzahl. Jede Ziffer steht für einen der drei Sätze, und sie ist die Summe aus: lesen = 4, schreiben = 2, ausführen = 1.

• 7 = 4+2+1 = rwx (alles)
• 6 = 4+2 = rw- (lesen + schreiben)
• 5 = 4+1 = r-x (lesen + ausführen)
• 4 = r-- (nur lesen)

Damit ergeben sich die zwei häufigsten Muster von selbst: 644 (rw-r--r--) für normale Dateien und 755 (rwxr-xr-x) für Verzeichnisse und Programme. stat zeigt beide Schreibweisen nebeneinander:

stat -c '%A %a %U %G %n' datei.txt ordner

-rw-r--r-- 644 root root datei.txt
drwxr-xr-x 755 root root ordner

Schritt 5: Rechte setzen mit chmod

chmod ändert die Rechte – entweder numerisch oder symbolisch. Numerisch setzt du alle drei Sätze auf einmal. So machst du eine Datei nur für Besitzer und Gruppe lesbar:

chmod 640 datei.txt
stat -c '%A %a %n' datei.txt

-rw-r----- 640 datei.txt

Symbolisch änderst du gezielt einzelne Bits: u (user/Besitzer), g (group), o (others), a (all), mit +/-/=:

chmod u+x,g-r datei.txt
stat -c '%A %a %n' datei.txt

-rwx------ 700 datei.txt

Schritt 6: Besitz übertragen mit chown

Wem eine Datei gehört, änderst du mit chown – im Format benutzer:gruppe:

chown koch:koch datei.txt
stat -c '%A %a %U %G %n' datei.txt

-rwx------ 700 koch koch datei.txt

Für einen ganzen Verzeichnisbaum hängst du -R (rekursiv) an – genau das brauchst du ständig bei Docker-Volumes, wenn ein Container als bestimmter Benutzer schreiben muss:

chown -R koch:koch /opt/meineapp/data

Was passiert, wenn die Rechte fehlen? Als koch eine nur-für-root lesbare Datei öffnen:

su - koch -c "cat /tmp/secret.txt"

cat: /tmp/secret.txt: Permission denied

Genau diese Meldung ist der häufigste Rechte-Fehler überhaupt – jetzt weißt du, dass sie nichts Kaputtes bedeutet, sondern das Modell wie vorgesehen greift.

Schritt 7: Gruppen – gemeinsamer Zugriff

Gruppen bündeln Benutzer, die auf dieselben Dateien zugreifen sollen. Ein Benutzer wird mit usermod -aG (append to Group) einer weiteren Gruppe hinzugefügt:

usermod -aG docker koch
id koch

uid=1000(koch) gid=1000(koch) groups=1000(koch),990(docker)

Das -a ist entscheidend: Ohne -a ersetzt usermod -G alle Nebengruppen, statt eine hinzuzufügen – so fliegt man versehentlich aus sudo oder docker. Zwei Gruppen begegnen dir ständig:

• sudo – wer hier Mitglied ist, darf mit vorangestelltem sudo Befehle als root ausführen.
• docker – wer hier Mitglied ist, darf Docker steuern. Das ist praktisch, aber sicherheitsrelevant: Zugriff auf den Docker-Socket ist faktisch Root-Zugriff (siehe Warnung unten).

Schritt 8: sudo statt Dauer-Root

Als root eingeloggt zu bleiben ist gefährlich: Ein Tippfehler löscht das halbe System, und jeder kompromittierte Prozess läuft mit vollen Rechten. Der sichere Weg ist ein normaler Benutzer in der Gruppe sudo, der einzelne Befehle bei Bedarf erhöht:

usermod -aG sudo koch

Danach führt koch administrative Befehle mit vorangestelltem sudo aus (sudo apt update) und wird nach seinem eigenen Passwort gefragt. Das ist nachvollziehbar (jede Aktion steht im Log unter /var/log/auth.log), reversibel und deutlich sicherer als ein Dauer-Root-Login. Genau darauf baut das Tutorial SSH absichern auf, wenn es den direkten Root-Login abschaltet.

Wenn es nicht funktioniert

Wartung & Backups

• Rechte sind selten Wartungsaufgabe, aber ein Audit lohnt sich. Suche gelegentlich nach weltweit schreibbaren Dateien – ein häufiges Sicherheitsleck: find /opt -perm -0002 -type f. Treffer solltest du mit chmod o-w entschärfen.
• Der Docker-Socket ist Root-Äquivalent. ls -l /var/run/docker.sock zeigt Besitz root:docker – wer in der Gruppe docker ist, kann Container mit gemountetem Host-Dateisystem starten und damit alles lesen und schreiben. Nimm nur vertrauenswürdige Konten in diese Gruppe.
• Backups brauchen die Rechte mit. Wenn du Daten sicherst, achte darauf, dass Besitz und Rechte erhalten bleiben – restic und rsync -a tun das automatisch. Sonst gehört nach einem Restore plötzlich alles root, und Dienste starten nicht mehr. Wie das sauber läuft, zeigt Backups mit Restic.