Berechtigungen und Eigentümer: Zugriffskontrolle

Berechtigungen und Eigentümer: Zugriffskontrolle

POSIX-Berechtigungen mit rwx-Notation und Oktal-Schreibweise. Unterschied zwischen Datei- und Verzeichnis-Berechtigungen. chown und chmod für Eigentümer- und Rechte-Änderungen.

Jede Datei und jedes Verzeichnis auf Unix-Systemen hat einen Eigentümer, eine Gruppe und Berechtigungen. Diese drei Informationen steuern, wer Dateien lesen, ändern oder ausführen darf. Das Konzept stammt aus den 1970ern und schützt Multi-User-Systeme vor unbeabsichtigten Änderungen und unbefugtem Zugriff.

Die Berechtigungen werden in drei Kategorien unterteilt: Eigentümer (User), Gruppe (Group) und Andere (Others). Jede Kategorie kann drei Rechte haben: Lesen (read), Schreiben (write) und Ausführen (execute). Diese neun Bits definieren die Zugriffsrechte - mehr braucht Unix nicht für funktionale Zugriffskontrolle.

Das Berechtigungs-System verstehen

Die drei Rechte-Kategorien

$ ls -l /home/michael/dokumente/bericht.pdf
-rw-r--r-- 1 michael users 45632 Okt  6 14:23 bericht.pdf

Die Ausgabe zeigt zehn Zeichen am Anfang: -rw-r--r--. Das erste Zeichen (-) bezeichnet den Dateityp - ein Bindestrich für normale Dateien, d für Verzeichnisse. Die verbleibenden neun Zeichen teilen sich in drei Gruppen zu je drei Zeichen:

  • rw- (Zeichen 2-4): Rechte des Eigentümers (michael)
  • r– (Zeichen 5-7): Rechte der Gruppe (users)
  • r– (Zeichen 8-10): Rechte aller anderen Benutzer

Der Eigentümer kann die Datei lesen und schreiben (rw-), die Gruppe nur lesen (r--), andere Benutzer ebenfalls nur lesen (r--). Niemand außer dem Eigentümer kann die Datei ändern oder löschen.

Read, Write, Execute im Detail

Read (r) erlaubt das Lesen einer Datei. cat bericht.pdf funktioniert mit r-Recht, ohne r-Recht kommt “Permission denied”. Bei Verzeichnissen ermöglicht r das Auflisten der Inhalte mit ls.

Write (w) erlaubt das Ändern einer Datei. Der Editor kann speichern, Daten anhängen funktioniert. Ohne w-Recht sind Dateien read-only - selbst der Eigentümer kann nicht speichern, es sei denn er ändert erst die Berechtigungen. Bei Verzeichnissen erlaubt w das Anlegen, Löschen und Umbenennen von Dateien.

Execute (x) macht Dateien ausführbar. Shell-Scripts oder Binaries benötigen x-Recht zum Starten. Ohne x-Recht zeigt ./script.sh einen Permission-Fehler. Bei Verzeichnissen bedeutet x die Berechtigung zum Betreten - cd /pfad erfordert x-Recht auf /pfad.

Eigentümer und Gruppe

$ ls -l script.sh
-rwxr-xr-x 1 michael developers 2048 Okt  6 15:30 script.sh

Die Datei gehört Benutzer michael und Gruppe developers. Jeder Benutzer kann Mitglied mehrerer Gruppen sein. Der Befehl id zeigt die eigenen Gruppenzugehörigkeiten:

$ id michael
uid=1000(michael) gid=1000(michael) groups=1000(michael),27(sudo),1001(developers)

Michael ist Mitglied der Gruppen michael (primäre Gruppe), sudo (darf Root-Befehle ausführen) und developers. Neue Dateien erhalten automatisch die primäre Gruppe des Erstellers. Das Kommando newgrp wechselt temporär die primäre Gruppe.

Die Gruppe ermöglicht Team-Arbeit ohne globale Berechtigungen. Alle Mitglieder von developers können script.sh lesen und ausführen, aber nur michael kann es ändern. Andere Benutzer (nicht in der Gruppe) können das Script ebenfalls lesen und ausführen, aber nicht ändern.

Berechtigungen ändern mit chmod

Symbolische Notation

Das chmod-Kommando (change mode) ändert Berechtigungen. Die symbolische Notation verwendet Buchstaben: u für User (Eigentümer), g für Group, o für Others, a für all (alle drei Kategorien).

$ chmod u+x script.sh

Das fügt dem Eigentümer (u) das Ausführungsrecht (x) hinzu (+). Die Datei wird ausführbar für den Eigentümer. Bestehende Rechte bleiben unverändert.

$ chmod go-w datei.txt

Das entfernt (-) das Schreibrecht (w) für Gruppe (g) und Andere (o). Nur der Eigentümer kann noch schreiben. Das u fehlt - Eigentümer-Rechte bleiben wie sie sind.

$ chmod a+r info.txt

Das gibt allen (a) Leserecht (r). Eigentümer, Gruppe und Andere können die Datei lesen. Existierende Rechte bleiben erhalten, nur r wird hinzugefügt.

Mehrere Änderungen lassen sich kombinieren:

$ chmod u+x,go-w script.sh

Das macht das Script für den Eigentümer ausführbar und entfernt Schreibrechte für Gruppe und Andere. Das Komma trennt die Operationen.

Oktal-Notation

Die Oktal-Schreibweise nutzt drei Ziffern von 0-7. Jede Ziffer kodiert drei Bits (rwx) als Summe: r=4, w=2, x=1. Die erste Ziffer gilt für den Eigentümer, die zweite für die Gruppe, die dritte für Andere.

$ chmod 755 script.sh

Das setzt Berechtigungen auf rwxr-xr-x:

  • 7 für Eigentümer: r(4) + w(2) + x(1) = 7 = rwx
  • 5 für Gruppe: r(4) + x(1) = 5 = r-x
  • 5 für Andere: r(4) + x(1) = 5 = r-x

Eigentümer kann alles, Gruppe und Andere können lesen und ausführen. Typische Berechtigung für ausführbare Dateien, die andere nutzen sollen.

$ chmod 644 dokument.txt

Das ergibt rw-r--r--:

  • 6 für Eigentümer: r(4) + w(2) = 6 = rw-
  • 4 für Gruppe: r(4) = 4 = r–
  • 4 für Andere: r(4) = 4 = r–

Standard-Berechtigungen für Textdateien - Eigentümer kann schreiben, alle anderen nur lesen. Dokumente, Konfigurationsdateien oder Source-Code nutzen oft 644.

$ chmod 600 privat.key

Das setzt rw-------:

  • 6 für Eigentümer: r(4) + w(2) = 6 = rw-
  • 0 für Gruppe: keine Rechte
  • 0 für Andere: keine Rechte

Nur der Eigentümer hat Zugriff. SSH-Keys erfordern diese Berechtigungen - SSH verweigert den Login mit zu offenen Key-Dateien.

Häufige Berechtigungs-Muster

Oktal Symbolisch Bedeutung Typische Nutzung
755 rwxr-xr-x Eigentümer alles, andere lesen+ausführen Ausführbare Programme
644 rw-r–r– Eigentümer schreiben, andere lesen Textdateien, Konfiguration
600 rw——- Nur Eigentümer lesen+schreiben Private Dateien, SSH-Keys
700 rwx—— Nur Eigentümer vollständiger Zugriff Private Scripts, persönliche Verzeichnisse
444 r–r–r– Alle nur lesen, niemand schreiben Read-only Daten
777 rwxrwxrwx Alle Rechte für alle Unsicher - niemals verwenden

Die 777-Berechtigung ist ein Sicherheitsrisiko. Jeder Benutzer kann die Datei ändern oder löschen. Temporäre Debugging-Situationen rechtfertigen es manchmal - produktiv nie.

Verzeichnis-Berechtigungen

Execute-Recht bei Verzeichnissen

Bei Verzeichnissen hat das Execute-Recht (x) eine spezielle Bedeutung: Es erlaubt das Betreten des Verzeichnisses mit cd. Ohne x können Benutzer nicht in das Verzeichnis wechseln, selbst wenn sie Leserechte haben.

$ ls -ld /home/michael/projekte/
drwxr-xr-x 12 michael michael 4096 Okt  6 14:45 projekte/

Das d am Anfang zeigt ein Verzeichnis. Die Berechtigungen rwxr-xr-x bedeuten:

  • Eigentümer: Lesen, schreiben, betreten (rwx)
  • Gruppe: Lesen, betreten (r-x)
  • Andere: Lesen, betreten (r-x)

Alle können cd /home/michael/projekte/ ausführen und mit ls den Inhalt auflisten. Nur der Eigentümer kann Dateien anlegen, löschen oder umbenennen.

Read ohne Execute

$ chmod 744 verzeichnis/

Das setzt rwxr--r-- für ein Verzeichnis. Gruppe und Andere haben nur r (read), nicht x (execute). Sie können nicht cd verzeichnis/ ausführen, obwohl sie theoretisch den Inhalt auflisten dürften. Ohne x ist das Verzeichnis unbetretbar - ls schlägt fehl mit “Permission denied”.

Diese Kombination ist selten nützlich. Verzeichnisse brauchen meist r und x zusammen (r-x), sonst ist das Lesen nutzlos.

Write für Verzeichnisse

Das Schreibrecht (w) bei Verzeichnissen erlaubt das Anlegen, Löschen und Umbenennen von Dateien im Verzeichnis. Es gilt unabhängig von den Berechtigungen der Dateien selbst.

$ ls -ld projekt/
drwxrwxr-x 5 michael developers 4096 Okt  6 15:12 projekt/

$ ls -l projekt/wichtig.txt
-r--r--r-- 1 sandra developers 1024 Okt  3 10:22 wichtig.txt

Das Verzeichnis projekt/ hat rwxrwxr-x - Eigentümer und Gruppe können schreiben. Die Datei wichtig.txt ist read-only (r--r--r--), gehört sandra.

Michael kann wichtig.txt trotzdem löschen, weil er Schreibrecht im übergeordneten Verzeichnis hat. Die Datei-Berechtigungen schützen nur den Inhalt, nicht die Existenz der Datei. Das Verzeichnis-Recht entscheidet über Löschen.

Typische Verzeichnis-Berechtigungen

Oktal Symbolisch Bedeutung Nutzung
755 rwxr-xr-x Eigentümer schreibt, andere navigieren Normale Benutzer-Verzeichnisse
775 rwxrwxr-x Eigentümer und Gruppe schreiben Team-Projekte
700 rwx—— Nur Eigentümer Zugriff Private Verzeichnisse
1777 rwxrwxrwt Alle schreiben, nur Eigentümer löscht /tmp mit Sticky Bit

Das Sticky Bit (erste Ziffer 1 in Oktal) bei Verzeichnissen erlaubt allen das Anlegen von Dateien, aber nur dem Eigentümer der Datei (oder des Verzeichnisses) das Löschen. /tmp nutzt das - jeder kann temporäre Dateien anlegen, aber niemand kann fremde Dateien löschen.

Eigentümer ändern mit chown

Benutzer und Gruppe ändern

Das chown-Kommando (change owner) ändert den Eigentümer einer Datei. Nur Root kann chown verwenden - normale Benutzer dürfen Dateien nicht an andere übertragen. Das verhindert Umgehung von Quota-Systemen (Speicherplatzbeschränkungen pro Benutzer).

$ sudo chown sandra dokument.txt

Die Datei gehört jetzt sandra. Die Gruppe bleibt unverändert. Sandra kann jetzt die Berechtigungen ändern und als Eigentümerin agieren.

$ sudo chown sandra:developers dokument.txt

Das ändert Eigentümer zu sandra und Gruppe zu developers. Der Doppelpunkt trennt Benutzer und Gruppe. Beide werden in einem Kommando geändert.

$ sudo chown :admins datei.txt

Nur die Gruppe wird geändert (zu admins), der Eigentümer bleibt. Der Doppelpunkt ohne Benutzer-Namen ändert nur die Gruppe.

Rekursive Änderungen

Die Option -R (recursive) ändert Berechtigungen für ganze Verzeichnisbäume:

$ sudo chown -R michael:developers /opt/projekt/

Alle Dateien und Unterverzeichnisse in /opt/projekt/ gehören jetzt michael mit Gruppe developers. Das ist praktisch nach Archiv-Extraktion oder bei Verzeichnis-Übernahmen.

$ sudo chmod -R 755 /opt/projekt/bin/

Alle Dateien in /opt/projekt/bin/ und Unterverzeichnissen bekommen 755. Scripts und Programme werden ausführbar. Die rekursive Änderung spart Zeit gegenüber einzelnen chmod-Aufrufen.

Vorsicht: Rekursive chmod kann Schaden anrichten. chmod -R 777 / mit Root-Rechten würde das gesamte System für alle beschreibbar machen - fatal für Stabilität und Sicherheit. Immer zweimal prüfen vor rekursiven Befehlen.

Spezielle Berechtigungs-Bits

SetUID - Ausführen als Eigentümer

Das SetUID-Bit (Set User ID) erlaubt einem Programm, mit den Rechten seines Eigentümers zu laufen statt mit den Rechten des Benutzers, der es startet. Das ist mächtig und potentiell gefährlich.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Mai 28  2024 /usr/bin/passwd

Das s in rws zeigt SetUID. Das passwd-Programm gehört root. Normale Benutzer können es ausführen - es läuft dann mit Root-Rechten. Das ist nötig, weil passwd die /etc/shadow-Datei ändern muss, die nur für Root lesbar ist.

Ohne SetUID könnte kein normaler Benutzer sein Passwort ändern - /etc/shadow ist strikt geschützt. Mit SetUID wird passwd temporär zu Root, ändert die Datei, beendet sich. Der Benutzer bekommt nie Root-Rechte, nur das Programm.

SetUID funktioniert nur bei ausführbaren Dateien, aus Sicherheitsgründen nicht bei Scripts. Ein SetUID-Script könnte durch Umgebungsvariablen manipuliert werden - zu gefährlich.

$ chmod u+s programm
$ chmod 4755 programm

Beide Befehle setzen das SetUID-Bit. Die symbolische Notation verwendet u+s, die Oktal-Notation eine führende 4 (4755 statt 755). Das s erscheint dann bei ls -l im Eigentümer-Execute-Feld.

SetGID - Ausführen als Gruppe

Das SetGID-Bit (Set Group ID) funktioniert ähnlich wie SetUID, aber für Gruppen. Programme laufen mit den Rechten der Datei-Gruppe, nicht der Gruppe des ausführenden Benutzers.

$ chmod g+s programm
$ chmod 2755 programm

Die Oktal-Notation nutzt eine führende 2 (2755). Das s erscheint im Gruppen-Execute-Feld bei ls -l.

Bei Verzeichnissen hat SetGID eine andere Bedeutung: Neue Dateien im Verzeichnis erben automatisch die Gruppe des Verzeichnisses, nicht die primäre Gruppe des Erstellers. Das ist nützlich für Team-Verzeichnisse.

$ ls -ld /opt/team-projekt/
drwxrwsr-x 8 michael developers 4096 Okt  6 16:20 team-projekt/

Das s in der Gruppen-Spalte (rws) zeigt SetGID. Alle Dateien, die in diesem Verzeichnis angelegt werden, gehören automatisch zur Gruppe developers - egal wer sie erstellt. Das vereinfacht Team-Arbeit, alle Gruppenmitglieder haben gleiche Rechte an neuen Dateien.

Sticky Bit - Nur Eigentümer löscht

Das Sticky Bit bei Verzeichnissen verhindert, dass Benutzer fremde Dateien löschen können, selbst wenn sie Schreibrecht im Verzeichnis haben. Nur der Eigentümer einer Datei (oder des Verzeichnisses, oder Root) kann die Datei löschen.

$ ls -ld /tmp/
drwxrwxrwt 15 root root 4096 Okt  6 16:45 /tmp/

Das t am Ende (rwt statt rwx) zeigt das Sticky Bit. Das /tmp-Verzeichnis hat 1777 - alle können Dateien anlegen, aber nicht fremde Dateien löschen. Benutzer A kann eine Datei von Benutzer B lesen (wenn die Berechtigungen das erlauben), aber nicht löschen.

$ chmod +t verzeichnis/
$ chmod 1777 verzeichnis/

Die symbolische Notation verwendet +t, die Oktal-Notation eine führende 1 (1777). Das Sticky Bit macht Sinn für gemeinsam genutzte Verzeichnisse wie /tmp, wo alle Benutzer temporäre Dateien ablegen.

Kombinierte Spezial-Bits

Die Spezial-Bits können kombiniert werden:

Oktal Bedeutung
4755 SetUID, normale Berechtigungen rwxr-xr-x
2755 SetGID, normale Berechtigungen rwxr-xr-x
1777 Sticky Bit, alle Rechte rwxrwxrwx
6755 SetUID + SetGID
7755 Alle drei Spezial-Bits

Die erste Oktal-Ziffer kodiert die Spezial-Bits: 4=SetUID, 2=SetGID, 1=Sticky. Die Addition kombiniert sie: 4+2=6 für SetUID+SetGID, 4+2+1=7 für alle drei.

Praktische Anwendungen

Sicherer Script-Zugriff

Ein Script backup.sh soll Backups erstellen, aber nur der Admin soll es ändern können:

$ sudo chown root:admins backup.sh
$ chmod 750 backup.sh

Das ergibt rwxr-x---: Root kann alles, die Gruppe admins kann das Script ausführen (Backups starten), normale Benutzer haben keinen Zugriff. Das Script selbst ist geschützt gegen Manipulation.

Team-Projekt-Verzeichnis

Ein Projekt-Verzeichnis für ein Entwickler-Team:

$ sudo mkdir /opt/projekt
$ sudo chown michael:developers /opt/projekt
$ sudo chmod 2775 /opt/projekt

Das setzt rwxrwsr-x mit SetGID. Alle Team-Mitglieder (Gruppe developers) können Dateien anlegen, ändern, löschen. Neue Dateien gehören automatisch zur Gruppe developers. Andere Benutzer können den Inhalt sehen (r-x), aber nicht ändern.

Private Home-Verzeichnisse

Benutzer-Home-Verzeichnisse sollten privat sein:

$ chmod 750 /home/michael

Das setzt rwxr-x---: Michael hat volle Kontrolle, seine Gruppe kann das Verzeichnis betreten und lesen (nützlich für gemeinsame Dateien), andere Benutzer haben keinen Zugriff. Standardmäßig sind Home-Verzeichnisse oft 755 - alle können lesen. Das 750 ist sicherer.

Web-Server-Verzeichnisse

Ein Web-Server benötigt Leserechte für HTML-Dateien, aber keine Schreibrechte:

$ sudo chown www-data:www-data /var/www/html
$ sudo chmod 755 /var/www/html
$ find /var/www/html -type f -exec chmod 644 {} \;
$ find /var/www/html -type d -exec chmod 755 {} \;

Verzeichnisse bekommen 755 (navigierbar), Dateien 644 (lesbar). Der Web-Server-Prozess (läuft als www-data) kann alles lesen, aber nichts ändern. Upload-Verzeichnisse brauchen 755 oder 775 für Schreibzugriff.

Umask und Standard-Berechtigungen

Umask verstehen

Die umask (user file creation mask) definiert, welche Berechtigungen bei neu erstellten Dateien und Verzeichnissen automatisch entfernt werden. Sie ist eine Subtraktion von den maximalen Berechtigungen.

$ umask
0022

Die Standard-umask ist meist 022. Neue Dateien starten theoretisch mit 666 (rw-rw-rw-), Verzeichnisse mit 777 (rwxrwxrwx). Die umask wird subtrahiert:

  • Dateien: 666 - 022 = 644 (rw-r–r–)
  • Verzeichnisse: 777 - 022 = 755 (rwxr-xr-x)

Eine umask von 077 entfernt alle Rechte für Gruppe und Andere:

  • Dateien: 666 - 077 = 600 (rw——-)
  • Verzeichnisse: 777 - 077 = 700 (rwx——)

Alle neu erstellten Dateien sind dann privat. Das ist sicherer, aber weniger praktisch für Team-Arbeit.

$ umask 002

Das setzt umask temporär auf 002. Neue Dateien bekommen 664 (rw-rw-r–), Verzeichnisse 775 (rwxrwxr-x). Die Gruppe kann schreiben - gut für Team-Verzeichnisse. Die Änderung gilt nur für die aktuelle Shell-Session. Permanente Änderungen gehören in ~/.bashrc oder /etc/profile.

Standard-Berechtigungen überprüfen

$ touch testdatei
$ mkdir testverzeichnis
$ ls -ld testdatei testverzeichnis
-rw-r--r-- 1 michael michael    0 Okt  6 17:15 testdatei
drwxr-xr-x 2 michael michael 4096 Okt  6 17:15 testverzeichnis/

Neue Dateien haben 644, neue Verzeichnisse 755 - das entspricht der Standard-umask 022. Das sichert Balance zwischen Zugänglichkeit und Schutz - der Eigentümer kann schreiben, andere nur lesen.

Berechtigungen debuggen

Zugriff überprüfen

Das ls -l-Kommando zeigt Berechtigungen, aber manchmal reicht das nicht zum Verstehen von “Permission denied”-Fehlern. Das namei-Kommando zeigt den kompletten Pfad mit allen Berechtigungen:

$ namei -l /home/michael/projekte/website/index.html
f: /home/michael/projekte/website/index.html
drwxr-xr-x root    root    /
drwxr-xr-x root    root    home
drwxr-x--- michael michael michael
drwxr-xr-x michael michael projekte
drwxr-xr-x michael michael website
-rw-r--r-- michael michael index.html

Der Zugriff auf index.html erfordert Execute-Rechte auf alle Verzeichnisse im Pfad. Das /home/michael-Verzeichnis hat drwxr-x--- - nur Eigentümer und Gruppe können es betreten. Andere Benutzer scheitern beim cd /home/michael - sie erreichen index.html nie, selbst wenn die Datei selbst lesbar wäre.

Effektive Berechtigungen prüfen

Das getfacl-Kommando zeigt erweiterte ACLs (Access Control Lists), falls gesetzt:

$ getfacl datei.txt
# file: datei.txt
# owner: michael
# group: developers
user::rw-
group::r--
other::r--

ACLs erlauben feinere Berechtigungen als die Standard-rwx-Mechanik - einzelne Benutzer oder zusätzliche Gruppen können spezifische Rechte bekommen. Die meisten Systeme nutzen ACLs selten - rwx reicht für fast alle Situationen.

Sicherheits-Überlegungen

Niemals 777 verwenden

Die Berechtigung 777 (rwxrwxrwx) ist fast immer falsch. Jeder kann die Datei lesen, ändern, löschen. Ein bösartiger Benutzer kann Malware einschleusen, Daten stehlen, das System kompromittieren.

Debugging-Situationen verleiten manchmal zu chmod 777 - “es funktioniert jetzt endlich”. Das ist gefährlich. Die korrekte Lösung findet die richtigen Berechtigungen, nicht die offensten. Ein Web-Upload-Verzeichnis braucht vielleicht 775, aber nie 777.

SetUID mit Bedacht

SetUID-Programme laufen mit erhöhten Rechten. Bugs oder Sicherheitslücken in SetUID-Root-Programmen sind kritisch - sie erlauben Privilege Escalation. Jedes zusätzliche SetUID-Programm erhöht die Angriffsfläche.

Nur vertrauenswürdige, gut gewartete Programme sollten SetUID haben. Eigene Scripts niemals SetUID machen - zu fehleranfällig. Stattdessen sudo mit spezifischen Regeln verwenden.

Regelmäßige Audits

$ find / -perm -4000 -ls 2>/dev/null

Das findet alle SetUID-Dateien auf dem System. Eine unbekannte SetUID-Datei ist verdächtig - möglicherweise ein kompromittiertes System oder falsch konfigurierte Software.

$ find /var/www -type f -perm -002 -ls

Das findet alle Dateien unter /var/www, die für alle beschreibbar sind (-002). Web-Server-Dateien sollten nie world-writable sein - ein Sicherheitsrisiko.

Zusammenfassung

Unix-Berechtigungen mit rwx für User, Group und Others sind einfach aber effektiv. Die Oktal-Notation (644, 755, 600) ist kompakt und schnell zu lesen. SetUID, SetGID und Sticky Bit erweitern das System für spezielle Anforderungen.

Normale Dateien brauchen meist 644 (Eigentümer schreibt, andere lesen). Ausführbare Programme 755 (Eigentümer schreibt, alle führen aus). Private Daten 600 (nur Eigentümer). Verzeichnisse entsprechend 755 oder 700. Diese vier Muster decken 90% der Situationen ab.

Der nächste Artikel behandelt Links zwischen Dateien - Hard Links und symbolische Links - und erklärt das Inode-Konzept, das hinter Berechtigungen und Dateinamen steht.


Verwendete Software und Versionen

Diese Betrachtung bezieht sich auf:

  • POSIX-Berechtigungen: Standard seit Unix V7 (1979)
  • Betriebssysteme: Alle Linux-Distributionen und BSD-Systeme
  • Kontext: Universal für alle Unix-artigen Systeme
  • Stand: Oktober 2025

Weiterführende Schritte:

michael von den Drachen

Softwareentwickler seit den 80ern. Systemkritiker seit immer. Betreibt produktive OpenBSD/Debian-Infrastruktur und entwickelt eigenes API-Gateway (furt).
Mehr über michael →
Berechtigungen und Eigentümer: Zugriffskontrolle
← Nächster Artikel Links und Dateitypen: Flexible Nutzung
Berechtigungen und Eigentümer: Zugriffskontrolle
Vorheriger Artikel → Dateisystem-Hierarchie: Der Verzeichnisbaum