Zugriffsrechte reparieren #Info

zurück zur Übersicht

Welchen Zweck erfüllen die Installer-Pakete im Verzeichnis /Library/Receipts/ und was haben sie mit der Option Zugriffsrechte reparieren im Festplatten-Dienstprogramm zu tun?

/Library/Receipts/

Wenn man selbst oder irgendwer anders einen Apple-Installer baut (also ein Installationspaket mit Apples PackageMaker erstellt), so hat dieser anschließend eine klar definierte Struktur. Im Unterverzeichnis Contents liegen mindestens die folgenden Elemente:

Wird nun ein solches Installer Package auf einem Mac installiert, wandert der komplette Installer -- allerdings ohne Archive.pax -- anschließend in /Library/Receipts/.

Das macht es einem selbst im Nachhinein simpel möglich, nachzuschauen, was man überhaupt schon so alles installiert hat, was die Installer konkret hinterlassen haben (lsbom -p MUGsf Archive.bom) und welche Skripte evtl. noch ihr Unwesen getrieben haben (die liegen in Resources und beinhalten welche, die vor/nach der Installation ausgeführt werden und bspw. ältere Versionen einer Software löschen, manchmal auch ganze Platten, etc.)

Die Installer Receipts werden aber noch an mindestens drei anderen Stellen von Apple genutzt:

  1. Rechte Reparieren -- von vielen gerne als täglicher Frühsport zur unreflektierten Ausübung empfohlen -- benutzt einige der Receipts dazu, die passenden Eigentümerschaften/Berechtigungen wiederherzustellen.

  2. Software Aktualisieren benutzt ebenfalls die Receipts, um in der Kommunikation mit den Apple-Servern die richtigen Pakete melden respektive anfordern zu können (swscan.apple.com, swquery.apple.com)

  3. Andere Installer-Packages prüfen im Rahmen der sogenannten preflight- oder VolumeCheck-Skripts anhand des Inhalts des /Library/Receipts/ Ordners, ob auf einem spezifischen Volume die Bedingungen für die Installation erfüllt sind (bspw. würde ein DRM-verseuchtes iTunes nachgucken wollen, ob auch schon ein DRM-verseuchtes Quicktime vorhanden ist)

Daraus ergibt sich eine generelle Regel: Finger weg von dem Ordner, wenn man sich keinen Ärger einhandeln will.

Zugriffsrechte reparieren

Dieses Prozedere -- egal ob per Festplatten-Dienstprogramm oder per diskutil verifyPermissions|repairPermissions (vergleiche mit diskutil(8)) angestossen, ist kein Allheilmittel für Berechtigungsprobleme gleich welcher Art. Ganz im Gegenteil dient es lediglich dazu, Eigentümerschaften/Berechtigungen ganz spezifischer Ordner zu überprüfen bzw. zu reparieren. Hierzu werden, wie schon weiter oben erwähnt, nur einige Installer Receipts von Apples Standardinstallation benutzt.

Das entsprechende DiskManagement Framework, das die eigentliche Arbeit macht, schaut nun in die passenden Installer Receipts, so vorhanden, und nur das, was dort drin steht (übrigens dort immer als relativer Pfad -> ./Library/... bspw.) wird anschließend

  1. relativ zu / oder
  2. wenn ein Device oder dessen Mountpoint zusätzlich angegeben wurde, dann relativ zu diesem

wieder in den Zustand zurückversetzt, den es laut Installer Receipt haben soll. Der erste Fall hat den großen Vorteil, daß auch Symlinks oder eingehängte Partitionen ebenfalls korrekt behandelt werden, was beim zweiten Fall nicht bzw. nur eingeschränkt stattfindet (Symlinks mit relativem Ziel innerhalb derselben Partition).

Daher wohl Apples Vorgabe, den Vorgang nur auf das aktuell gebootete System anzuwenden, weil andernfalls die Anwendung von Rechte Reparieren noch mehr Placebo-Charakter hat, als normalerweise eh schon der Fall.

Ein Beispiel: Hat man sich selbst oder ein unfreundlicher 3rd-Party Installer die Berechtigungen für das Programm-Verzeichnis /Applications verbogen, so daß es nun wie folgt heißt (ls -l /Applications):

drwxrwxrwx  86 admin  admin       2924 26 Apr 14:37 Applications

so würde ein Anwenden von Rechte Reparieren das Ganze wieder auf die passenden Berechtigungen/Eigentümerschaften zurücksetzen:

drwxrwxr-x      root    admin           ./Applications

(nachzuprüfen mittels lsbom -p MUGsf /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | head)

Was ist dabei geschehen? Vor dem Anwenden hätte wäre /Applications von jedem Benutzer auch beschreibbar gewesen. Laut Apple soll das aber nur Mitgliedern der Gruppe admin und dem root-Benutzer möglich sein, so daß Änderungen am Programmordner nur nach Authentifizierung möglich sind, da man ja als besonnener Mensch das Tagesgeschäft am Mac mit einem Account erledigt, der keine Admin-Berechtigungen beinhaltet.

Wie kommt es überhaupt dazu, daß die Anwendung von Rechte Reparieren notwendig werden könnte? Entweder man hat das Ganze selbst verbastelt (durch Herumspielen mit irgendwelchen Shell-Befehlen oder durch die entsprechenden Möglichkeiten im Infofenster des Finders) oder durch Installation von Software, deren Autor beim Erstellen der Installer zu wenig Sorgfalt hat walten lassen (dummerweise kann ein Installer auch die Rechte bereits existenter Ordner modifizieren)

Aber nicht jedes dieser Malheurs kann von Rechte Reparieren wieder behoben werden. Manche Teile des Dateisystems bleiben komplett außen vor, bspw. /Library/StartupItems (was fatale Konsequenzen haben kann) oder auch der Inhalt der Benutzer-Homes unterhalb /Users. Und wenn man Rechte Reparieren in Situationen mit mehr als einer eingehängten Partition oder Symlinks auf andere Partitionen nicht auf das aktuell gebootete System anwendet, dann kann es sein, daß es am eigentlichen Ziel vorbei operiert, da den Links auf die anderen Partitionen in diesem Modus nicht gefolgt werden kann. Es macht also Sinn, Apples Vorgabe zu folgen und immer nur das jeweils gebootete System zu behandeln...

Übrigens: Apple führte mit 10.2 noch einen Mechanismus ein, um dem etwas unflexiblen Konzept des ausschließlichen Betrachten der Installer Receipts (die ja den Stand der Dinge zum Release-Zeitpunkt des Betriebsystems repräsentieren) Rechnung zu tragen, bspw. weil sich durch ein Security Update etwas an den Zugriffsberechtigungen nachträglich ändern musste. Etwaige Ausnahmen werden seitdem in einer Datei namens HintFile.plist zusammengetragen. Sollte man also permanent über die Meldung "We are using special permissions for..." stolpern, so ist dies erstmal kein genereller Anlaß zur Sorge sondern eher ein Indiz dafür, daß Apple seinen Installationsmechanismus an ein paar Stellen dringend nachbessern sollte.

Thomas Kaiser in BCB148E4.3C078%Thomas.Kaiser@phg-online.de und BCA9C5C1.3B824%Thomas.Kaiser@phg-online.de + Ergänzungen per E-Mail.

#Info

Diese Seite ist ein Teil von De.Soc.Mac.
Zuletzt geändert am May 28, 2009, 10:37 a.m..

Impressum Lizenz