Forum

Access Control Lists (ACL)
Oktober 14, 2007, 14:43:56
Seit mit OS X unser OS zu einem Mehrbenutzer-OS geworden ist, kennen wir Macianer Datei-Berechtigungen, welche definieren, wer was mit welcher Datei anstellen darf. Kennen ist bei vielen von uns zwar wohl etwas übertrieben. Aber wir sind ihnen alle zumindest schonmal begegnet, diesen Berechtigungen. Zumindest in den Datei-Informations-Dialogen (Apfel-i) im Finder unter Eigentümer und Berechtigungen.
Standardmässig sind wir mit den simplen (alles ist relativ  ;)) POSIX-Berechtigungen bedient. Diese werden in unzähligen Büchern und auf ebensovielen Web-Sites erklärt (eine deutschsprachige ist z.B. jene der FH Wiesbaden).  Ich spare mir hier somit den unzähligundersten Erklärungsversuch.
Durch ausgeklügelte Planung lassen sich mit den POSIX-Berechtigungen durchaus auch komplexere Zugriffsszenarien in Mehrbenutzer-Umgebungen in den Griff kriegen. Wer sich an so etwas aber schon heran gewagt hat oder heranwagen musste, der kam womöglich doch nicht umhin, die Nutzer von Betriebssystemen (ja, auch Windows) zu beneiden, welche mit sogenannten Access Control Lists (ACL) feinere Steuerungen dieser Berechtigungen erlauben. Seit Tiger (10.4) gibt es allerdings keinen Grund mehr für diesen Neid, kennt Mac OS X doch nun ebenfalls ACLs. Zwar lassen sich ACLs nur mit der Server-Version von Mac OS X mittels grafischer Oberfläche einschalten und verwalten. Damit umgehen kann aber auch die normale Client-Version von OS X. Nur bedarf es hier halt einer Konfiguration der Sache via Terminal. Wie das funktioniert, wollen wir uns in diesem Artikel etwas näher anschauen. (Alternativ zum Terminal lassen sich ACLs natürlich auch mit Drittsoftware verwalten, z.B. TinkerTool System.)
Damit auf einem bestimmten Laufwerk (genauer auf einem Dateisystem) ACLs benutzt werden können, muss diese Funktion auf dem Dateisystem erst eingeschaltet werden. Dazu dient das Tool fsaclctl. Mit der Option -e (für enable) werden ACLs eingeschaltet, mit -d (für disable) werden sie ausgeschaltet. Mit der Option -p wird der Pfad des Mountpoint des Dateisystems übergeben, für welches ACLs eingeschaltet werden sollen. Ohne Angabe einer Option -e oder -d wird der gegenwärtige Status ausgegeben. Zum Ändern des Status muss das Tool als root laufen. Schauen wir uns also mal an, wie das auf dem Root-Verzeichnis meines MBP (unter Tiger) aussieht:
[Gran:~] blasi% fsaclctl -p /
Access control lists are not supported or currently disabled on /.
Schalten wir die ACLs also mal ein (ab Leopard sind ACLs bereits standardmässig aktiviert und das Einschalten somit nicht nötig):
[Gran:~] blasi% sudo fsaclctl -e -p /Danach muss ein Neustart bzw. ein Remount des Dateisystems durchgeführt werden. Dann sieht die Statusmeldung so aus:
[Gran:~] blasi% fsaclctl -p /
Access control lists are supported on /.
Nun kann ich also loslegen und die Zugriffsrechte auf einzelne Objekte (Dateien oder Verzeichnisse) definieren, indem ich Einträge, sogenannte Access Control Entrys (ACE),  in ihre (beim ersten Eintrag automatisch erstellte) ACL mache. ACEs hinzugefügt und entfernt, ACLs sortiert und geändert und die Vererbung verändert werden können mit dem Tool chmod, das wir schon von der Defintion der simplen POSIX-Rechte her kennen. Mit der +a Option kann ich z.B. ein ACE hinzufügen:
[Gran:~/acltest] blasi% chmod +a "blasi allow read" testdatei.txtLasse ich mir nun ein Dateilisting anzeigen, dann deutet ein + nach den normalen POSIX-Regeln darauf hin, dass für diese Datei eine ACL existiert:
[Gran:~/acltest] blasi% ls -l testdatei.txt
-rw-r--r-- + 1 blasi  blasi  15 Oct 13 22:10 testdatei.txt
Mit der zusätzlichen Option -e zeigt ls diese ACL auch an:
[Gran:~/acltest] blasi% ls -le testdatei.txt
-rw-r--r-- + 1 blasi  blasi  15 Oct 13 22:10 testdatei.txt
 0: user:blasi allow read
Mit der -a Option kann ein Eintrag wieder entfernt werden:
[Gran:~/acltest] blasi% chmod -a "blasi allow read" testdatei.txt
[Gran:~/acltest] blasi% ls -le testdatei.txt
-rw-r--r-- + 1 blasi  blasi  15 Oct 13 22:10 testdatei.txt

Während mit den normalen POSIX-Rechten Einfluss aufs Lesen, Schreiben und Ausführen genommen werden kann, erlauben ACLs eine weit differenziertere Einflussnahme auf verschiedenste Aktionen. In den ACEs können Rechte für folgende Aktionen erteilt (allow) oder entzogen (deny) werden:
Auf alle Arten von Objekten anwendbar sind:
delete Löschen des Objekts. Das Löschen kann durch dieses Recht am Objekt selbst oder durch das delete_child Recht am enthaltenden Verzeichnis erlaubt werden.
readattr Lesen der Basis-Attribute des Objekts. Dieses Recht wird implizit gewährt, wenn das Nachschlagen (look up) des Objekts möglich und das Recht nicht explizit entzogen ist.
writeattr Schreiben der Basis-Attribute.
readexattr Lesen der erweiterten Attribute.
writeexattr Schreiben der erweiterten Attribute.
readsecurity Lesen der erweiterten Sicherheitsinformationen (ACL).
writesecurity Schreiben von Sicherheits-Informationen (Eigentümer, Modus, ACL).
chown Ändern des Eigentümers.
Nur auf Verzeichnisse anwendbar sind:
list Inhalt auflisten
search Nachschlagen (look up) von Dateien mit ihrem Namen
add_file Hinzufügen von Dateien.
add_subdirectory Hinzufügen von Unterverzeichnissen.
delete_child Löschen von enthaltenen Objekten. Siehe auch das delete Recht weiter oben.
Nur auf Nicht-Verzeichnisse anwendbar sind:
read Öffnen zum Lesen.
write Öffnen zum Schreiben.
append Öffnen zum Schreiben, aber so, dass nur in Dateibereichen geschrieben werden kann, die beim Öffnen nicht schon beschrieben waren.
execute Ausführen des Skripts oder Programms.
Die Vererbung von Rechten kann mit folgenden Befehlen gesteuert werden, die nur auf Verzeichnisse anwendbar sind:
file_inherit Vererbung auf Dateien.
directory_inherit Vererbung auf Verzeichnisse.
limit_inherit Diese Option ist nur bei vererbten Einträgen an Unterverzeichnissen relevant; sie bewirkt, dass bei den vererbten Einträgen die directory_inherit Option gelöscht wird und so weiter verschachtelte Unterverzeichnisse die Option nicht mehr erben. Die Vererbung wird damit auf eine einzige Stufe beschränkt.
only_inherit Die Einträge werden weiter vererbt, beim Auswerten der ACL aber nicht berücksichtigt.

In der Einleitung haben wir gehört, dass es in der Nicht-Server Version von OS X keine grafische Oberflächen zur Verwaltung von ACLs gibt. Allerdings können ACLs in der grafischen Oberflächen zumindest gesehen werden. Der Finder passt nämlich den Eigentümer und Rechte Abschnitt im Datei-Informations-Dialog (Apfel-i) bei Vorhandensein einer ACL entsprechend an:

Das ist zwar nett, aber so wie das Apple umgesetzt hat, leider absolut nutzlos. Wir werden gleich sehen weshalb.

Ein paar Dinge sind beim Einsatz von ACLs wichtig und müssen unbedingt verstanden werden:
a) ist eine ACL vorhanden, wird sie zuerst konsultiert! Wenn jemand versucht, auf eine Datei zuzugreifen und ein ACE passt, dann wird die "darf er oder darf er nicht"-Suche abgebrochen und die normalen POSIX-Regeln kommen nicht mehr ins Spiel. Gibt es keine zutreffende ACL-Regel dann kommen die normalen POSIX-Regeln der Datei zum Tragen.
b) schauen wir uns im Terminal noch einmal ein Dateilisting an:
[Gran:~/acltest] blasi% ls -le
total 0
drwxr-xr-x + 2 blasi  blasi  68 Oct 14 11:41 Testverzeichnis
 0: user:chef deny list,delete
 1: group:staff allow list
 2: user:blasi allow list
Wir sehen, dass jedem ACE eine Nummer vorangestellt ist. Das ist das absolut Wichtigste, das man berücksichtigen muss. ACLs sind wie Firewall-Regeln. Sie werden in genau der aufgeführten Reihenfolge abgearbeitet und die erste zutreffende Regel kommt zum Tragen und bestimmt die Berechtigung. (Und das ist der Grund, weshalb die Anzeige im Finder nutzlos ist. Vergleicht man oben die Reihenfolge der Regeln im Terminal und die vom Finder angezeigte Reihenfolge sieht man, dass die Anzeige im Finder leider nicht korrekt ist.)
Im obigen Beispiel wird dem Benutzer chef die list Berechtigung verweigert, selbst wenn er Mitglied der Gruppe staff ist (im Finder ist das allerdings nicht ersichtlich). Wie mit Firewall-Regeln können wir damit also sehr komplexe Regeln aufstellen, in welchen wir sehr präzise festlegen können, was welcher Benutzer tun darf. (Umfangreiche Regelwerke sollten allerdings sehr gut durchdacht werden, können sie doch rasch ziemlich unübersichtlich werden.)
Selbstverständlich erlaubt uns chmod auch, die Reihenfolge unserer Regeln (ACEs) im Griff zu behalten. Mit der Option +a# lassen sich ACE an einer spezifischen Position einfügen:
[Gran:~/acltest] blasi% chmod +a# 1 "max deny list" Testverzeichnis
[Gran:~/acltest] blasi% ls -lde Testverzeichnis
drwxr-xr-x + 2 blasi  blasi  68 Oct 14 11:41 Testverzeichnis
 0: user:chef deny list,delete
 1: user: max deny list
 2: group:staff allow list
 3: user:blasi allow list
Analog dazu können mit -a# spezifische ACEs entfernt werden:
[Gran:~/acltest] blasi% chmod -a# 1 Testverzeichnisentfernt den Eintrag "max deny list". Mit der Option =a# lassen sich Einträge an Ort ändern:
[Gran:~/acltest] blasi% chmod =a# 1 "staff deny list" Testverzeichnisändert unseren staff allow Eintrag in einen staff deny.

ACLs sind Teil der Metadaten, jener zusätzlichen Daten einer Datei also, die nicht in der Datei selbst, sondern vom Dateisystem irgendwo (opak) intern mitgespeichert werden. Die Verwendung von Dateisystemen mit aktivierten ACLs mit Systemungebungen, die keine ACLs unterstützen, stellt dadurch kein Problem dar. Zwar entfalten die ACLs in solchen Systemumgebungen (also z.B. Panther) naheliegenderweise keine Wirkung (sondern einzig die POSIX-Rechte), die dortige Bearbeitung der Dateien beeinträchtigt die ACLs aber nicht. Diese bleiben unangetastet bestehen und entfalten ihre Wirkung wieder, sobald das Dateisystem wieder in einer Systemumgebung gemountet wird, die ACLs unterstützt.
ACLs sind aber insofern spezielle Metadaten, als sie vor Änderungen durch andere als die dafür vom System vorgesehenen Methoden (chmod, die GUI in OS X Server) geschützt sind. Und anders als die übrigen Metadaten werden sie beim Kopieren einer Datei (z.B. mit cp, aber auch mit rsync!) nicht mitkopiert. (mv funktioniert auf der selben Partition, da der Inode nicht wirklich geändert wird.)
Zu erwähnen bleibt noch, dass ACLs bei einer Serververbindung respektiert werden. Greifen also z.B. Panther-Clients auf einem Tiger-Server zu, welcher ACLs einsetzt, dann finden die ACLs Beachtung, auch wenn der Client an sich nichts von ACLs weiss.

Noch ungeklärte Frage: Wie verhält sich OS X, wenn ACLs auf einem Dateisystem, das keine Metadaten unterstützt (z.B. FAT32), aktiviert werden soll? Wird mit ._ Präfixen gearbeitet oder ist die Verwendung von ACLs nicht möglich? Ich kann das mangels einer FAT32 Partition hier leider nicht testen.

Quelle: Der Beitrag basiert lose auf einem englischsprachigen Artikel von Ed Marczak, der 2005 im MacTech Magazine erschinen ist.
« Letzte Änderung: Dezember 09, 2007, 11:24:02 von warlord »
_______
Complete liberty of contradicting and disproving our opinion, is the very condition which justifies us in assuming its truth for purposes of action; and on no other terms can a being with human faculties have any rational assurance of being right. (John Stuart Mill - On Liberty)

VollPfosten

  • Never mind the Pfosten!
Re: [Entwurf] Access Control Lists (ACL)
Antwort #1: Oktober 19, 2007, 20:33:55
Gibt es so etwas wie umask auch für ACLs, d. h. lässt sich leicht festlegen, mit welchen ACLs neue Dateien oder Verzeichnisse in einem bestimmten Verzeichnis angelegt werden?

mbs

Re: [Entwurf] Access Control Lists (ACL)
Antwort #2: Oktober 19, 2007, 21:36:43
Zitat
Gibt es so etwas wie umask auch für ACLs, d. h. lässt sich leicht festlegen, mit welchen ACLs neue Dateien oder Verzeichnisse in einem bestimmten Verzeichnis angelegt werden?

Dazu muss man zwei Dinge sagen:
1) Eine umask legt nicht wirklich fest, welche Rechte neue Objekte bekommen. Sie legt sozusagen das Gegenteil fest, nämlich welche Rechte laufende Programme auf keinen Fall vergeben dürfen.

2) Wie warlord schon erwähnt hat, kann ein Ordner mit einer Kombination von 4 verschiedenen "inherit"-Zugriffsmarkierungen versehen werden, woraus sich 12 sinnvolle "inherit"-Einstellungen ergeben. Diese Einstellungen steuern, auf welche Weise dieser Ordner ACLs auf die in ihm liegenden Objekte vererbt.

Das heißt, jeder Ordner legt eine Art Standardrecht fest, das automatisch für neu angelegte Objekte in ihm angewandt wird. Das was Du meintest, lässt sich also schon "leicht" festlegen.

Der Umgang mit ACLs und gerade mit den inherit-Einstellungen ist allerdings nicht wirklich als "leicht" zu bezeichnen: Jeder Unterordner kann wieder inherit-Einstellungen definieren, wodurch sich in der Ordnerhierarchie mehrere Vererbungen "mischen", spätere Änderungen der inherit-Einstellungen eines Oberordners können sich auch nachträglich auf enthaltene Objekte auswirken, in einem Unterobjekt explizit gesetzte ACLs mischen sich mit den ererbten ACLs, Widersprüche zwischen ererbten und gesetzten ACLs müssen durch ACL-Umwandlung aufgelöst werden, usw. ...

VollPfosten

  • Never mind the Pfosten!
Re: [Entwurf] Access Control Lists (ACL)
Antwort #3: Oktober 21, 2007, 13:46:35
Danke für die Erklärung!

Ich hatte bisher nur auf einem Webserver das Vergnügen, mit setfacl usw. hantieren zu müssen und empfand das als einfacher Benutzer schon recht kompliziert und umständlich. Dass sich die lieben Sysadmins da mal richtig austoben können, ist nachvollziehbar :-)