Ein Dateisystem verwaltet üblicherweise Berechtigungseinstellungen für jedes gespeicherte Element – ​​in der Regel Dateien und Verzeichnisse –, die die Bearbeitung von Dateisystemelementen entweder erlauben oder verweigern. Oftmals ermöglichen diese Einstellungen die Zugriffskontrolle basierend auf Funktionen wie Lesen, Ändern, Navigieren und Ausführen sowie für verschiedene Benutzer und Benutzergruppen.

Eine etablierte Technologie wurde für Unix entwickelt , später von POSIX kodifiziert und wird in Linux verwendet [ 1 ] . Eine weitere gängige Technologie ist die Zugriffskontrollliste (ACL), von der verschiedene Varianten in Dateisystemen implementiert sind und eine von POSIX kodifiziert wurde. Da POSIX sowohl die ältere Unix-basierte Technologie als auch ACLs definiert, wird erstere der Einfachheit halber als traditionelle POSIX-Berechtigungen bezeichnet , obwohl dieser Begriff nicht allgemein bekannt ist.

Eine berechtigungsbasierte Benutzeroberfläche passt die dem Benutzer zur Verfügung stehenden Funktionen an die Dateisystemberechtigungen an. Beispielsweise kann die Oberfläche Menüoptionen ausblenden, die aufgrund der für ein Element gespeicherten Berechtigungen nicht zulässig sind.

Geschichte

CTSS

Ein frühes Time-Sharing- System, das Compatible Time-Sharing System (CTSS), unterstützte mehrere Benutzer; jedes Benutzerkonto hatte eine „Problemnummer“ und eine „Programmierernummer“. [ 2 ]

Die erste Version des CTSS-Dateisystems unterstützte lediglich zwei „schreibgeschützte“ Dateimodi. Einer davon konnte vom Benutzer, der andere nur mithilfe von Bearbeitungskarten, die an das Rechenzentrum übermittelt wurden, aufgehoben werden. [ 2 ] : 45–46 Dateien konnten zwischen Benutzern desselben Projekts geteilt werden; die geteilten Dateien wurden dem Programmierer mit der Nummer Null zugewiesen. [ 2 ] : 24 Es gab keinen weiteren Schutz als den durch die Schreibschutzbits gewährleisteten.

Die zweite Version des Dateisystems verfügt über separate Berechtigungsbits für „schreibgeschützt“ und „schreibgeschützt“; letzteres erlaubt nur das Anhängen von Dateien. Es gibt außerdem ein „privates“ Bit, das nur dem Autor der Datei den Zugriff erlaubt, und ein „geschütztes“ Bit, das nur dem Autor der Datei erlaubt, die Dateiberechtigungen zu ändern. [ 3 ]

Multics

Benutzer im Multics -Time-Sharing-System besitzen eine „Person_id“, Projekte eine „Project_id“. Ein Benutzer meldet sich mit seiner Person_id und seiner Project_id am System an. Eine Datei enthält eine Zugriffssteuerungsliste (ACL) mit Einträgen, die eine Person_id oder ein „*“, eine Project_id oder ein „*“ und ein „Instanz-Tag“ oder ein „*“ enthalten. Ein Instanz-Tag repräsentiert einen Prozesstyp; ein „a“ steht beispielsweise für einen Prozess aus einer regulären interaktiven Sitzung. Die Einträge in einer ACL werden mit der Person_id, der Project_id und dem Instanz-Tag des Prozesses abgeglichen. Ein „*“ ist ein Platzhalter, der alle Person_ids, Project_ids oder Instanz-Tags abdeckt. Der ACL-Eintrag mit den wenigsten übereinstimmenden Platzhaltern wird verwendet. [ 4 ] : 6–2, 6-46-8

Eine ACL für eine Datei verfügt über die Zugriffsrechte „Lesen“, „Schreiben“ und „Ausführen“; eine ACL für ein Verzeichnis verfügt über die Zugriffsrechte „Status“ (ermöglicht das Lesen von Attributen von Dateien und Verzeichnissen im Verzeichnis), „Ändern“ (ermöglicht das Ändern von Attributen von Dateien und Verzeichnissen im Verzeichnis sowie das Entfernen von Elementen aus dem Verzeichnis) und „Anhängen“ (ermöglicht das Hinzufügen neuer Elemente zum Verzeichnis). [ 4 ] : 6-3

TENEX

Ein Benutzer in TENEX gehört zu einer Gruppe. [ 5 ] : 44

Eine Datei oder ein Verzeichnis verfügt über eine Reihe von Berechtigungsbits: sechs Bits für die Berechtigungen des Datei- oder Verzeichnisbesitzers, sechs Bits für die Berechtigungen anderer Benutzer in der Datei- oder Verzeichnisgruppe und sechs Bits für sonstige Benutzer. Bei einer Datei lauten die Berechtigungsbits „Lesen“, „Schreiben“, „Ausführen“, „Anhängen“ und „Jede Seite der Datei hat ihre eigenen Berechtigungen“, wobei das sechste Bit nicht verwendet wird. Bei einem Verzeichnis lauten die Berechtigungsbits „Zugriff erlaubt“ (wenn nicht gesetzt, ist kein Zugriff auf das Verzeichnis erlaubt), „Dateien im Verzeichnis können geöffnet werden“ (vorbehaltlich der Dateiberechtigungsbits), „Besitzerähnliche Funktionen können ohne Dateipasswort ausgeführt werden“ und „Dateien können dem Verzeichnis hinzugefügt werden“, wobei das fünfte und sechste Bit nicht verwendet werden. [ 5 ] : 42–44

TOPS-10

Ein Benutzerkonto in TOPS-10 verfügt über eine Programmierernummer und eine Projektnummer.

Eine Datei verfügt über Berechtigungsbits: drei Bits für die Berechtigungen des Dateibesitzers, drei Bits für die Berechtigungen anderer Benutzer mit derselben Projektnummer wie der Besitzer und drei Bits für alle übrigen Benutzer. Das Betriebssystem kann so konfiguriert werden, dass es jedes Konto mit einer Programmierernummer, die mit der Programmierernummer des übergeordneten Verzeichnisses übereinstimmt, als Besitzer behandelt oder nur ein Konto mit derselben Programmierernummer und Projektnummer wie das übergeordnete Verzeichnis als Besitzer. Die Werte der Berechtigungsbits sind:

  • 7 - Keine Zugriffsrechte, außer dass der Eigentümer die Datei aufrufen kann, um ihre Berechtigungen zu ändern;
  • 6 - Nur ausführen;
  • 5 - lesen und ausführen;
  • 4 - anhängen, lesen und ausführen;
  • 3 - aktualisieren, anhängen, lesen und ausführen;
  • 2 - schreiben, aktualisieren, anhängen, lesen und ausführen;
  • 1 - umbenennen, schreiben, aktualisieren, anhängen, lesen und ausführen;
  • 0 - Berechtigungen ändern, umbenennen, schreiben, aktualisieren, anhängen, lesen und ausführen.

Der Eigentümer darf die Berechtigungen jederzeit ändern. [ 6 ]

UNIX- und Unix-ähnliche Systeme

In der ersten Version von Unix (v1) hatten Dateien fünf Berechtigungsbits:

  • schreiben, Nicht-Eigentümer;
  • gelesen, Nicht-Eigentümer;
  • schreiben, Eigentümer;
  • gelesen, Besitzer;
  • ausführbar;

und ein Set-UID-Bit . [ 7 ] Es kannte keine Gruppen. Dies blieb bis zur dritten Auflage (v3) so; [ 8 ] die vierte Auflage (v4) führte Gruppen ein, und Dateien in v4 hatten neun Berechtigungsbits:

  • gelesen, Besitzer;
  • schreiben, Eigentümer;
  • ausführen, Eigentümer;
  • lesen, gruppieren;
  • schreiben, gruppieren;
  • ausführen, Gruppe;
  • lesen, andere;
  • schreiben, andere;
  • ausführen, andere;

sowie ein Set-UID- und ein Set-GID-Bit ; [ 9 ] Dies ist derselbe Satz von Berechtigungen, der in POSIX spezifiziert ist und der von aktuellen Unix- und Unix-ähnlichen Systemen bereitgestellt wird .

Beispiele

Dateisystemberechtigungen wurden auf vielfältige Weise implementiert. Einige bemerkenswerte Beispiele werden hier beschrieben.

NTFS, das in vielen Windows- Versionen, einschließlich der aktuellen , enthalten ist, verwendet ACLs zur berechtigungsbasierten Zugriffskontrolle; NTFS-ACLs gelten als leistungsstark, aber auch komplex. [ 10 ]

Linux- Dateisysteme wie ext2 , ext3 , ext4 und Btrfs unterstützen sowohl POSIX-Berechtigungen als auch POSIX.1e-ACLs. Es gibt experimentelle Unterstützung für NFSv4-ACLs für ext3- [ 11 ] und ext4-Dateisysteme.

FreeBSD unterstützt POSIX.1e-ACLs auf UFS sowie NFSv4-ACLs auf UFS und ZFS. [ 12 ] [ 13 ]

HFS und sein Nachfolger HFS+ , wie sie in den Classic Mac OS- Betriebssystemen implementiert wurden, unterstützen keine Berechtigungen.

macOS unterstützt POSIX-konforme Berechtigungen, sowohl in HFS+ als auch in APFS . Ab Version 10.4 („Tiger“) werden zusätzlich zu POSIX-konformen Berechtigungen auch NFSv4-ACLs unterstützt. Das Apple Mac OS X Server-Administrationshandbuch für Dateidienste ab Version 10.4 empfiehlt, nach Möglichkeit ausschließlich traditionelle Unix-Berechtigungen zu verwenden. macOS unterstützt weiterhin das Attribut „Protected“/„Locked“ des klassischen Mac OS als „unveränderliches“ Flag im 4.4BSD-Flagsfeld . [ 14 ]

Die Dateizuordnungstabelle (Originalversion) verfügt über ein dateispezifisches, schreibgeschütztes Attribut, das für alle Benutzer gilt.

OpenVMS definiert vier Zugriffsfunktionen: Lesen, Schreiben, Ausführen und Löschen sowie Benutzerauswahlen: System, Besitzer, Gruppe und Welt. Die Welt umfasst die Gruppe, welche wiederum den Besitzer einschließt, und das System wählt die Systembenutzer aus. Dieses Design ähnelt dem von Unix, bietet aber folgende bemerkenswerte Erweiterungen: die zusätzliche Funktion „Löschen“ und die zusätzliche Benutzerauswahl „System“. [ 15 ] Zugriffskontrolllisten (ACLs) werden ab VMS 4.0 unterstützt. [ 16 ]

Die Solaris -ACL-Unterstützung hängt vom verwendeten Dateisystem ab; das ältere UFS- Dateisystem unterstützt POSIX.1e-ACLs, während ZFS nur NFSv4-ACLs unterstützt. [ 17 ]

IBM z/OS implementiert Dateisicherheit mittels RACF (Resource Access Control Facility) [ 18 ].

Das AmigaOS-Dateisystem, AmigaDOS, unterstützt ein für ein Einzelbenutzer-Betriebssystem vergleichsweise fortschrittliches Berechtigungssystem. In AmigaOS 1.x besaßen Dateien die Berechtigungen/Flags Archivieren, Lesen, Schreiben, Ausführen und Löschen (zusammengefasst als ARWED). In AmigaOS 2.x und höher wurden zusätzlich die Berechtigungen/Flags Halten, Skripten und Rein hinzugefügt.

Das OpenHarmony -Betriebssystem nutzt zusammen mit seinem Client-Ökosystem in Oniro OS und HarmonyOS (mit den Versionen HarmonyOS NEXT) sowie dem Linux-basierten Server-Betriebssystem openEuler nativ sein Harmony Distributed File System (HMDFS), das einen Zugriffstoken-Manager ( rollenbasierte Zugriffskontrolle ) und die Core File Kit API mit granularer Berechtigungsverwaltung unterstützt, mit Ausnahme von openEuler, das eine feinere Berechtigungsverwaltung bietet . [ 19 ]

Traditionelle POSIX-Berechtigungen

Traditionell werden Dateiberechtigungen in Unix-basierten Dateisystemen durch POSIX.1 definiert. [ 20 ] Es spezifiziert drei Klassen (Benutzer, Gruppe und Andere), die die Zuordnung von Berechtigungen zu Benutzern ermöglichen, sowie drei Operationen (Lesen, Schreiben, Ausführen), die für jede Klasse erteilt oder verweigert werden können. Beim Erstellen einer Datei werden standardmäßig die Berechtigungen verwendet, die über den umaskBefehl zugänglich sind.

In einem Unix-basierten Dateisystem ist alles eine Datei, sogar Verzeichnisse und andere spezielle Dateien .

Klassen

Die Klassen legen fest, wie Berechtigungen einem Benutzer zugeordnet werden. Die Berechtigungen der Benutzerklasse gelten für den Benutzer, dem die Datei gehört. Die Berechtigungen der Gruppenklasse gelten für Benutzer der Gruppe , der die Datei gehört . Die Berechtigungen der Klasse „Andere“ gelten für alle anderen Benutzer.

Die effektiven Berechtigungen sind die Berechtigungen der Klasse, der der Benutzer zuerst angehört , und zwar in der Reihenfolge: Benutzer, Gruppe, dann andere. Beispielsweise besitzt der Besitzerbenutzer die effektiven Berechtigungen der Benutzerklasse, selbst wenn er Mitglied der Besitzergruppe ist.

Berechtigungen

Die folgenden Berechtigungen gewähren die entsprechenden Operationen an Dateien und Verzeichnissen:

Lesen (r)

  • Für Dateien: Gewährt die Berechtigung, den Inhalt der Datei zu lesen (nicht ihren Namen oder ihre Metadaten, die durch die Berechtigungen des übergeordneten Verzeichnisses bestimmt werden).
  • Für Verzeichnisse: Gewährt die Berechtigung, die Verzeichniseintragsnamen der darin enthaltenen Dateien und Verzeichnisse zu lesen, jedoch nicht, auf deren Metadaten ( Inode ) und damit auf deren Inhalt zuzugreifen, der durch die Ausführungsberechtigung des Verzeichnisses bestimmt wird .

Schreibe (w)

  • Für Dateien: Gewährt die Möglichkeit, den Inhalt der Datei zu ändern.
  • Für Verzeichnisse: Gewährt die Möglichkeit, Einträge im Verzeichnis zu ändern, d. h. Dateien oder Verzeichnisse zu erstellen, zu löschen und umzubenennen.
    • Dazu ist außerdem die Ausführungsberechtigung erforderlich , um auf die Metadaten ( Inodes ) aller darin enthaltenen Dateien und Verzeichnisse zuzugreifen . Ohne Ausführungsberechtigung ist die Schreibberechtigung daher praktisch bedeutungslos.

Führe (x) aus

  • Für Dateien: Gewährt die Berechtigung, eine Datei auszuführen. Diese Berechtigung muss für ausführbare Programme festgelegt werden, damit diese ausgeführt werden können.
    • Hierfür ist auch die Leseberechtigung erforderlich .
  • Für Verzeichnisse gilt: Die Ausführungsberechtigung gewährt die Möglichkeit, die Metadaten der darin enthaltenen Dateien und Verzeichnisse zu lesen, sofern deren Namen bekannt sind; die Namen selbst können jedoch nicht gelesen werden. Ein Verzeichnis ohne Ausführungsberechtigung blockiert effektiv das Lesen und Schreiben der Inhalte seiner enthaltenen Dateien und Verzeichnisse.
    • A directory with execute permission but without read permission effectively makes it a name guessing game to access the contents of its files and directories.

General access requirement inside directories

Accessing the content of file or directory inside a directory requires:

  1. Knowing its name which is discoverable if the parent directory read permission is set (or by guessing its name).
  2. The parent directory execute permission to access the file or directory inode.
  3. Its corresponding read, write or execute permissions.

Permission requirement summary for file operations

To read from a file you need:

  • The file read permission.
  • Execute permission on its parent directory .

To write to a file you need:

  • The file write permission.
  • Execute permission on its parent directory .

To execute a file you need:

  • The file read and execute permission.
  • Execute permission on its parent directory .

To know the name of the file you need:

  • Read permission of its parent directory .

To add, remove, or rename a file you need:

  • write, and execute permission on its parent directory.

Notes

Metadata of a file or directory typically includes inode id, file type, size, ownership (GUI and UID), and permission bits.

The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".[21]

Unlike ACL-based systems, these permissions are not inherited. Files created within a directory do not necessarily have the same permissions as its containing directory.

Changing permission behavior with setuid, setgid, and sticky bits

Three additional single-bit attributes apply to each file that are related to permissions and stored in the file mode along with permissions.

  • The set user ID, setuid, or SUID mode. Executing a file with this bit set results in a process with user ID set to the file's owning user. This enables users to be treated temporarily as root (or another user).
  • Die Berechtigung ` setgid` oder `SGID` legt die Gruppen-ID fest . Wird eine Datei mit diesem Bit ausgeführt, wird der Prozess so gestartet, dass die Gruppen-ID der Gruppe des Dateibesitzers entspricht. Wird diese Berechtigung auf ein Verzeichnis angewendet, erben neue Dateien und Verzeichnisse, die in diesem Verzeichnis erstellt werden, dessen Gruppe. (Standardmäßig wird die primäre Gruppe des aktuellen Benutzers verwendet, außer auf BSD-basierten Systemen, die sich so verhalten, als wäre das `setgid`-Bit für alle Verzeichnisse immer gesetzt (siehe ` Setuid` ).)
  • Der Sticky- Modus (auch Textmodus genannt ). Das klassische Verhalten des Sticky-Bits bei ausführbaren Dateien bestand darin, den Kernel dazu zu bewegen , das resultierende Prozessabbild nach Beendigung im Speicher zu behalten. Diese Verwendung des Sticky-Bits ist jedoch heutzutage auf wenige Unix-ähnliche Betriebssysteme ( HP-UX und UnixWare ) beschränkt. Bei einem Verzeichnis verhindert die Sticky-Berechtigung, dass Benutzer darin enthaltene Dateien anderer Benutzer umbenennen, verschieben oder löschen, selbst wenn sie Schreibrechte für das Verzeichnis besitzen. Nur der Verzeichnisbesitzer und der Superuser sind davon ausgenommen.

Darstellung

Berechtigungen werden üblicherweise in symbolischer oder Oktalnotation dargestellt.

Symbolische Notation

Die symbolische Notation wird im langen Ausgabeformat des Befehls verwendet ls -l.

Das erste Zeichen der Ausgabe gibt den Unix-Dateityp an . Dieser stellt keine Berechtigung dar, obwohl er neben den Berechtigungsinformationen steht. Die verbleibenden neun Zeichen repräsentieren die Berechtigungen für Benutzer, Gruppen und andere Klassen als Gruppen von Zugriffsberechtigungen für Lese-, Schreib- und Ausführungsoperationen. Eine Operation wird durch einen Bindestrich verweigert, durch ein Zeichen rfür Lese-, wSchreib- oder xAusführungsberechtigungen hingegen gewährt.

Beispiele:

  • -rwxr-xr-xDas erste Zeichen -kennzeichnet eine reguläre Datei; die nächsten drei Zeichen rwxbedeuten, dass die Benutzerklasse über alle Berechtigungen verfügt, während die Gruppe und andere Klassen (beide r-x) nur Lese- und Ausführungsrechte besitzen.
  • crw-rw-r--Das Präfix „:“ ckennzeichnet eine spezielle Zeichenkette. Dateien, Benutzer- und Gruppenklassen (beide rw-) verfügen über Lese- und Schreibrechte, während andere Klassen ( r--) nur Leserechte besitzen.
  • dr-x------Das Präfix „:“ dkennzeichnet ein Verzeichnis; die Benutzerklasse ( r-x) verfügt über Lese- und Ausführungsberechtigungen, während die Klassen „Gruppe“ und „Andere“ (beide ---) keine Berechtigungen besitzen.

Um die Attribute `setuid` , `setgid` und `sticky`/`text` darzustellen , wird das Zeichen an der dritten Position einer Klasse geändert, obwohl diese Position normalerweise nur für die Ausführung vorgesehen ist und diese Attribute die Datei unabhängig von der Klasse beeinflussen. Das Attribut `setuid` ändert das Ausführungszeichen für die Benutzerklasse, das Attribut `setgid` für die Gruppenklasse und das Attribut `sticky` oder `text` für die Klasse „Andere“. Für `setuid` oder `setgid` xwird `<setuid>` szu `<setgid>` und für das Attribut `sticky` oder `text` zu `<setgid> `. Beispielsweise -steht ` <setuid> ` für eine reguläre Datei, in der die Benutzerklasse Lese-, Schreib- und Ausführungsrechte besitzt, die Gruppenklasse Leserechte hat und die Klasse „Andere“ Lese- und Ausführungsrechte besitzt. Die Attribute `setuid` , `setgid` und `sticky` sind gesetzt. Sxt-T-rwsr-Sr-t

Einige Systeme zeigen zusätzliche Berechtigungsfunktionen an:

Oktalnotation

Berechtigungen werden häufig in Oktalschreibweise angezeigt , beispielsweise mit dem Befehl ` octal` stat -c %a. Die Notation besteht aus mindestens drei Ziffern. Die letzten drei Ziffern geben die Berechtigungsklasse an: Benutzer, Gruppe und Andere. Ist eine vierte Ziffer vorhanden, steht die erste für die drei speziellen Attribute: setuid , setgid und sticky .

Jeder Operationsberechtigung wird eine Bitposition zugewiesen, die für eine Oktalziffer Folgendes darstellt:

  • Lesen: links, binär 100, oktal 4
  • Schreiben Sie: Mitte, Binär 010, Oktal 2
  • Ausführen: rechts, binär 001, oktal 1

Der Wert einer Klassenberechtigung ist die Summe oder alternativ die logische ODER- Verknüpfung der Berechtigungen.

Beispiele:

SymbolischOktalBeschreibung
----------0000Keine Berechtigungen
-rwx------07:00 UhrNur für den Eigentümer lesen, schreiben und ausführen
-rwxrwx---0770Lesen, Schreiben und Ausführen für Eigentümer und Gruppe
-rwxrwxrwx0777Lesen, Schreiben und Ausführen für Eigentümer, Gruppe und andere
-rwxr-----0740Der Eigentümer kann lesen, schreiben und ausführen; die Gruppe kann nur lesen; alle anderen haben keine Berechtigungen.

private Benutzergruppe

Einige Systeme weichen vom traditionellen POSIX-Modell von Benutzern und Gruppen ab, indem sie für jeden Benutzer eine neue Gruppe – eine „benutzerprivate Gruppe“ – erstellen. Unter der Annahme, dass jeder Benutzer das einzige Mitglied seiner benutzerprivaten Gruppe ist, ermöglicht dieses Schema die Verwendung einer umask von 002, ohne dass andere Benutzer in neu erstellte Dateien in normalen Verzeichnissen schreiben können, da diese Dateien der privaten Gruppe des erstellenden Benutzers zugewiesen werden. Wenn jedoch die gemeinsame Nutzung von Dateien erwünscht ist, kann der Administrator eine Gruppe mit den gewünschten Benutzern erstellen, ein für die Gruppe beschreibbares Verzeichnis erstellen, das dieser neuen Gruppe zugewiesen wird, und – was am wichtigsten ist – das Verzeichnis mit setgid versehen. Dadurch werden die darin erstellten Dateien derselben Gruppe wie das Verzeichnis zugewiesen, und die umask 002 (ermöglicht durch die Verwendung benutzerprivater Gruppen) stellt sicher, dass andere Mitglieder der Gruppe in diese Dateien schreiben können. [ 22 ] [ 23 ]

Siehe auch

Referenzen

  1. ^ „Classic SysAdmin: Understanding Linux File Permissions“ . Abgerufen am 18. Juni 2026 .
  2. ^ a b c Das kompatible Time-Sharing-System: Ein Programmierhandbuch (PDF) . The MIT Press . 1963.
  3. ^ Das kompatible Time-Sharing-System: Ein Programmierhandbuch (PDF) (Zweite Auflage). The MIT Press . 1965. Abschnitt AD.2, S. 5.
  4. ^ a b Multics Programmierhandbuch Referenzhandbuch (PDF) . Honeywell . Dezember 1975.
  5. ^ a b TENEX Executive Manual (PDF) . BBN . April 1973.
  6. ^ DECsystem 10 Monitor Calls Manual (PDF) . DEC . Mai 1974.
  7. ^ Unix Programmer's Manual, Systemaufrufe, Teil 1 (PDF) . 3. November 1971. SYS CHMOD (II).
  8. ^ "Tarball der v3-Manpages; siehe stat.2" .
  9. ^ "Tarball der v4-Manpages; siehe stat.2" .
  10. ^ „Datei- und Ordnerberechtigungen“ . Microsoft. 9. Dezember 2009.
  11. ^ „Native NFSv4 ACLs unter Linux“ . Archiviert vom Original am 12. Oktober 2008. Abgerufen am 4. Mai 2010 .
  12. ^ "NFSv4_ACLs – FreeBSD Wiki" .
  13. ^ „FreeNAS 9.1.1 Benutzerhandbuch“ (PDF) . 2013. Archiviert vom Original (PDF) am 24. September 2015.
  14. ^ Gite, Vivek (3. Juni 2010). „Apple OS X: Schreibschutz für Dateien über die Befehlszeile“ .
  15. ^ „OpenVMS-Dokumentation“ . Archiviert vom Original am 5. März 2012. Abgerufen am 6. Juni 2009 .
  16. ^ „Dateisysteme: Schutz“ . CS322 Vorlesungsfolien .
  17. ^ „Oracle Solaris ZFS Administration Guide“ (PDF) . Sep 2010.
  18. ^ "IBM Knowledge Center" .{{cite web}}CS1-Wartung: Veralteter Archivierungsdienst ( Link )
  19. ^ „HarmonyOS Distributed File System Development Guide“ . Substack . LivingInHarmony Blog. 13. März 2024. Abgerufen am 13. März 2024 .
  20. ^ „Definitionen, 3.175 Dateiberechtigungsbits“ . pubs.opengroup.org . 22.07.2018 . Abgerufen am 24.06.2023 .
  21. ^ Hatch, Bri (24. April 2003). „Linux File Permission Confusion pt 2“ . Hacking Linux Exposed . Abgerufen am 6. Juli 2011 .
  22. ^ Epstein, Brian. „Das Wie und Warum von privaten Benutzergruppen in Unix“ . security.ias.edu . Institut für Netzwerksicherheit für fortgeschrittene Studien. Archiviert vom Original am 8. August 2014. Abgerufen am 5. August 2014 .
  23. ^ „Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directoryes“ . Red Hat Customer Portal . Red Hat.