Dateiberechtigungsmodelle im Vergleich: POSIX-Bits, POSIX-ACLs, NFSv4/ZFS-ACLs, NTFS und macOS-ACLs

Worum es geht

Modell	Gilt für	Lesebefehl	Schreibbefehl
POSIX-Mode-Bits	jedes Unix-ähnliche Dateisystem	ls -l FILE; oktal über stat -c %a FILE (GNU/Linux) oder stat -f %Lp FILE (FreeBSD/macOS)	chmod 640 FILE (oktal oder symbolisch)
POSIX.1e-ACLs	ext4, XFS und weitere unter Linux, UFS auf einigen BSDs	getfacl FILE	setfacl -m u:NAME:rw FILE
NFSv4-/ZFS-ACLs	ZFS und UFS (nfsv4acls) unter FreeBSD, ZFS unter Solaris/illumos (OpenZFS unter Linux verwendet stattdessen POSIX-ACLs)	FreeBSD: getfacl FILE (versteht sowohl POSIX.1e- als auch NFSv4-ACLs); illumos/Solaris: ls -V FILE	FreeBSD: setfacl -m mit Einträgen im NFSv4-Stil; illumos/Solaris: chmod A+ENTRY FILE
NTFS-ACLs (DACLs)	NTFS unter Windows	icacls FILE oder Get-Acl FILE	icacls FILE /grant "NAME:(R,W)" (in PowerShell in Anführungszeichen setzen, da dort Klammern ausgewertet werden) oder Set-Acl
macOS-ACLs	HFS+ und APFS, aufgesetzt auf die POSIX-Mode-Bits	ls -le FILE	chmod +a "NAME allow read,write" FILE

Warum es wichtig ist

Jedes Modell hat eine eigene Vererbungssemantik, eine eigene Art, Zugriff ausdrücklich zu verweigern (im Unterschied dazu, ihn bloss nicht zu gewähren) und einen eigenen Identitäts-Namensraum (numerische UIDs, SIDs oder die Verzeichnisdienst-Einträge von macOS). Nichts davon lässt sich sauber auf ein anderes Modell abbilden. Eine zwischen Systemen kopierte Datei behält nur das, was das Kopierwerkzeug übersetzt, und die meisten alltäglichen Werkzeuge (scp, Browser-Download, E-Mail-Anhang) behalten nichts davon.

So wird es angewendet

• POSIX-Mode-Bits als einzige Zugriffskontrollinformation behandeln, deren Erhalt bei einem Transfer zwischen Unix-ähnlichen Systemen garantiert ist; ACLs nach jeder systemübergreifenden Kopie separat mit getfacl/icacls/ls -le prüfen.
• Unter Windows ACLs vor einer Änderung sichern: icacls DIR\* /save acl.txt /t. Die Datei speichert Namen relativ zum Verzeichnis des gesicherten Pfads, daher muss /restore auf dieses übergeordnete Verzeichnis zielen: icacls DIR /restore acl.txt, nicht auf die Datei selbst.
• ACLs und Mode-Bits wirken je nach System unterschiedlich zusammen: Unter Linux setzen die Gruppenbits von chmod die ACL-Maske und können Einträge für benannte Benutzer einschränken; unter macOS werden ACL-Einträge vor den Mode-Bits ausgewertet, sodass ein Einschränken des Modus eine ACL-Freigabe nicht entzieht; unter ZFS schreibt chmod die ACL gemäss der Eigenschaft aclmode des Datasets um und kann dabei Einträge verwerfen.
• Bei plattformübergreifenden Freigaben (z. B. eine Samba-Freigabe auf einem POSIX-Dateisystem, die Windows-Clients mit NTFS-ähnlichen ACLs angeboten wird) die effektive Berechtigung sowohl von der Unix- als auch von der Windows-Seite testen, da die Abbildungsschicht fehlerhaft runden kann.

Stolpersteine

• GNU cp -a erhält Mode-Bits und POSIX-ACLs, rsync -a dagegen erhält ACLs nur mit -A (und erweiterte Attribute nur mit -X); keines von beiden überträgt NFSv4/ZFS-ACL-Einträge auf ein Dateisystem ohne NFSv4-ACL-Unterstützung.
• Annehmen, die chmod +a-Syntax unter macOS entspreche setfacl der BSDs: macOS-ACLs verwenden eine eigene chmod +a/-a-Syntax und nicht den POSIX.1e-Befehl setfacl, der unter macOS gar nicht mitgeliefert wird.
• Nach einem Vorfall nur die Mode-Bits wiederherstellen und die Berechtigungen für „repariert“ halten, obwohl ein übrig gebliebener ACL-Eintrag einer früheren Freigabe weiterhin Zugriff erlaubt, den ls -l nicht anzeigt.