Hallo svn,
das ist nicht ganz richtig, aber ich weiß, was Du meinst. Sofern das Sticky- oder SUID-Bit gesetzt ist, wird's in der Tat kritisch mit der Sicherheit. Dann nämlich wird jedes Programm als root ausgeführt (Sticky) bzw. als dessen Besitzer (SUID). Das mache ich aber grundsätzlich nie.
Mein Ansinnen ist eher das Erzwingen einer Sicherheitsrichtlinie, wie man es unter Windows kennt. Dort ist es per Default so, daß (neu angelegte) Dateien immer die Rechte des übergeordneten Verzeichnis bzw. Laufwerks erben und die Gruppe "BUILTIN/Administratoren" der Besitzer ist, außer in der ACL befindet sich der Platzhalter "ERSTELLERBESITZER" bzw. "EIGENTÜMERRECHTE". Das hat den enormen Vorteil, daß ein User in Ermangelung der Besitzerrechte die Zugriffskontolliste nicht einfach ändern kann, was nämlich ebenfalls zu einem Problem werden kann. Unter POSIX / Unix ist es per Default so, daß der Ersteller einer Datei immer der Besitzer ist und daher auch die Zugriffsrechte definieren darf. Wenn man aber - wie von mir angefragt - immer root als Besitzer hat, geht auch das nicht mehr und es kommen die erweiterten POSIX-ACLs zur Anwendung, sofern diese definiert wurden.
An dieser Stelle möchte ich noch anmerken, daß es mir nicht um das System-Laufwerk von OSX geht, sondern um ein Datenlager, das keinerlei Systemrelevante Dinge beherbergt. Solcherlei Vorhaben auf dem Macintosh-Volume sehe auch ich im günstigsten Fall als "experimentell" an.
Ich habe das Ganze leider nicht mit HFS+ lösen können, weil dem Treiber bzw. mount-Programm einige Optionen fehlen, um das Vorhaben umsetzen zu können. Daher habe ich das Volume mit NTFS formatiert und mit Tuxera gemountet, wobei ich folgenden Befehl verwende:
mount -t fusefs_txantfs -o uid=0,gid=0,umask=777,dmask=777,fmask=777,nosuid,extended_security /dev/disk2s1 /Volumes/RAID
Damit erzwingt man, daß der (merkwürdig programmierte) NTFS-Treiber alle Dateien dem Benutzer "root" und der Gruppe "wheel" zuordnet. u-, d- und fmask sagen dem Treiber, daß Owner, Group und Others ALLE keinerlei Zugriffsrechte haben. Das ist insofern nicht weiter dramatisch, da - bis auf zwei Ausnahmen, die normalerweise keine Rolle spielen - die Zugriffsüberprüfung für root (im Gegensatz zu Windows) ohnehin immer übergangen wird. Mit "nosuid" wird verhindert, daß ein auf dem Volume gespeichertes Programm mit den Rechten seines Besitzers ausgeführt werden kann. Der letzte Parameter aktiviert die erweiterten POSIX-ACLs, die der Treiber in den NTFS-eigenen "Alternate Data Streams" ablegt; die sind also nativ auf dem Volume gespeichert und gehen nach einer Neinstallation nicht verloren.
Auf diese Weise sind sämtliche POSIX-Altlasten (sorry, aber das Owner-Group-Others-System ist einfach nicht flexibel genug, egal welches Unix oder Linux man verwendet) de facto abgeschaltet und zur Auswertung der effektiven Berechtigungen kommen nur noch die erweiterten POSIX-ACLs zum Einsatz, die prinzipiell genauso flexibel und fein granuliert sind wie das Pendant aus der Windoof-Welt.
Die ACLs kann man nun entweder über den Finder konfigurieren, oder mit chmod - was sich allerdings als wenig ertragreich darstellt, weil chmod prinzipbedingt nicht gerade Userfreundlich ist und der Finder die meisten Optionen, die POSIX-ACLs bieten, gar nicht zur Verfügung stellt. Ich habe zwei Tools gefunden, mit denen man einigermaßen zurecht kommt, wenn man sie in Kombination einsetzt:
- Sandbox
- TinkerTool System
Wenn man eine frisch formatierte Platte einsetzt bzw. einmal konfigurierte ACLs nie wieder ändert, kann man sich auf Sandbox beschränken. Denn das "Problem" der Tools ist das Übertragen geänderter ACLs an bereits existierende, untergeordnete Dateien bzw. Ordner. In meinem Falle habe ich ein 13 TB großes RAID-Array, welches bereits zu etwa 90% gefüllt ist. Sandbox kann zwar ACLs "nach unten" propagieren, wendet diese Änderungen aber aus mir unverständlichen Gründen nur auf Ordner an, nicht auf Dateien (!). Das wiederum kann TinkerTool, allerdings kranken beide Programm an der Art und Weise, WIE sie die Rechte propagieren: Nämlich 1:1 und nicht den Einstellungen und der Ebenentiefe entsprechend "berechnete". So wird das "Inherited"-Flag zum Beispiel nicht automatisch gesetzt, weshalb man die Rechte mit Sandbox erstellen sollte um sie dann hinterher mit TinkerTool System zu propagieren.
Wenn jemand eine Idee hat, wie man das Ganze auf eine HFS-formatierte Platte anwendet oder bessere Tools zur Erledigung der Aufgaben kennt, würde ich mich sehr über eine Antwort freuen.
Viele Grüße,
Tobias Punke
PS: Eine Frage nochmal zum Abschluss: Welches Dateisystem haltet Ihr für "robuster"? NTFS oder HFS+? Ich selbst hatte mit NTFS noch nie Probleme mit einem defekten Dateisystem habe aber in meinen Experimenten welche mit HFS+ bekommen. Vielleicht habe ich allerdings auch irgendwelche Dinge falsch gemacht, weshalb ich die Frage nochmal gerne an Euch richten würde....
