macOS Mojave-Verzeichnisberechtigungen


10

MacOS Mojave hat die Auswirkungen von SIP auf die Home-Verzeichnisse der Benutzer ausgeweitet. Standardmäßig wird der Zugriff auf viele Verzeichnisse im Home-Verzeichnis eines Benutzers verweigert. Es folgen einige Beispiele für diese Verzeichnisse.

~/Library/Messages
~/Library/Mail
~/Library/Safari
[… etc.]

Um von einem Terminal aus auf diese Verzeichnisse zugreifen zu können, muss die Terminalanwendung unter Systemeinstellungen> Sicherheit und Datenschutz> Datenschutz> Vollständiger Festplattenzugriff definiert werden. Die Konfiguration funktioniert mit Ausnahme des folgenden Verzeichnisses auf meinem System. Das gleiche Verhalten kann für andere Daten in Containern auftreten - nicht sicher.

~/Library/Containers/com.apple.mail/Data/DataVaults

Das faszinierende Verhalten ist leicht zu reproduzieren. Das Verzeichnis ist nicht einmal sichtbar.

cd ~/Library/Containers/com.apple.mail/Data
ls
ls: DataVaults: Operation not permitted

Ich rsyncspiegele mein Home-Verzeichnis auf eine externe Festplatte. Ich kann dies jedoch nicht mehr tun, da rsyncsich "E / A-Fehler aufgetreten - Überspringen des Löschens von Dateien" beschwert, wodurch der Spiegelungseffekt unterbrochen wird. Ich finde keine Dokumentation zu diesem Thema. Apple Support hat keine Ahnung. Warum ist dieses Verzeichnis etwas Besonderes und wie können wir darauf zugreifen, ohne SIP zu deaktivieren?

Ergebnisse weiterer Untersuchungen mit deaktiviertem SIP

Laut Systeminformationen wurde das Mojave-Upgrade am 24. September 2018 durchgeführt. Das Verzeichnis wurde ebenfalls am selben Tag erstellt. Mein Benutzer besitzt das Verzeichnis und die Mitarbeitergruppe ist der Gruppeneigentümer. Seine Berechtigungen sind 0700. Es hat erweiterte Attribute, wie durch das @Symbol angezeigt . Keine ACLs. Keine Fahnen.

xattr -l ~/Library/Containers/com.apple.mail/Data/DataVaults

com.apple.quarantine: 0082;00000000;Mail;
com.apple.rootless: Mail

ls -lO DataVaults
(no result; exit 0)

Nach dem Deaktivieren von SIP, dem Löschen des Verzeichnisses und dem erneuten Aktivieren von SIP wird das Verzeichnis mit denselben Berechtigungen wieder angezeigt, sobald Mail geöffnet wird. Mail (Version 12.0 (3445.100.39)) hat keine Plugins.

Ergebnisse einer Neuinstallation am 16. Oktober 2018

Das Verzeichnis existiert nach dem Formatieren und erneuten Installieren nicht. Ich habe immer noch keine Ahnung, wie es jemals dort angefangen hat.

Ergebnisse eines Upgrades am 29. März 2019

Das Verzeichnis wurde zeitgleich mit dem Upgrade auf Mojave 10.14.4 (18E226) und / oder Mail Version 12.4 (3445.104.8) wieder angezeigt.


Das Verzeichnis ist entweder durch ein Dateiflag, eine ACL oder ein erweitertes Attribut geschützt. Ich habe festgestellt, dass viele der Dateien und Verzeichnisse das com.apple.quarantineAttribut beispielsweise nach einem Upgrade auf Mojave erhalten haben. Für meine eigenen Backups (mit resticHomebrew) ignoriere ich diese Teile einfach, ~/Libraryda mich keiner davon betrifft oder was ich normalerweise sowieso mache. Ich habe selbst 24 davon.
Kusalananda

Entschuldigung, ich habe Ihre Frage erneut gelesen und nach dem Hinzufügen von iTerm2 (in meinem Fall) zu den Apps mit "Vollständiger Festplattenzugriff" wird das Backup jetzt ohne Probleme ausgeführt (danke dafür!). Mehr kann ich zu Ihrem Fall nicht sagen. Auf meinem Rechner kann ich diese bestimmte Verzeichnis sehen und es enthält symbolische Links zu einigen der Verzeichnisse in meinem Home - Verzeichnis (die „default“ diejenigen mögen Documents, Movies, Musicetc.).
Kusalananda

Mehr kann ich nicht sagen. Ich habe dieses Verzeichnis / Symlink nicht. Haben Sie ein Upgrade oder eine Neuinstallation durchgeführt? Läutet "DataVaults" eine Glocke in Bezug auf eine Anwendung oder Funktion, die Sie zuvor verwendet haben?
Kusalananda

Antworten:


6

Das DataVaults-Verzeichnis hat mit Berechtigungen zu tun . Der Zugriff wird verhindert, es sei denn, der Inhaber der Berechtigung gewährt den Zugriff. Die Berechtigungen für Mail.app können wie folgt aufgelistet werden und bieten eine XML-Liste.

codesign -d --entitlements - /Applications/Mail.app/

Zu diesem Zeitpunkt besteht die einzige verbleibende Methode, um Zugriff auf das Verzeichnis zu erhalten, darin, SIP zu deaktivieren. In Bezug auf mein rsyncProblem habe ich mich dafür entschieden, SIP eingeschaltet zu lassen, und die rsysncOption genutzt, excludeum das DataVaults-Verzeichnis zu ignorieren, das übrigens keinen Inhalt enthält.

Aus einem Kommentar des Blogs der Eclectic Light Company , der weitere Hinweise bietet:

/var/folders/t9/[long ID]/C/com.apple.QuickLook.thumbnailcache”ist ein DataVault, ein neuer Typ von Datenschutzcontainern, den Apple irgendwann um 10.13.4 eingeführt hat. Diese Dateien / Ordner werden durch das Dateiflag "UF_DATAVAULT" gekennzeichnet. Diese werden über SIP implementiert (technisch gesehen kein Sandboxing, aber das Gleiche). Anwendungen benötigen eine Berechtigung zum Erstellen oder Zugreifen auf bestimmte Datentresore oder sogar zum stat () eines DataVault-Ordners.

Diese Geräte sind eine eingehendere Untersuchung wert. Apple gibt diese Berechtigungen nicht an Dritte weiter (und hat anscheinend auch keine Pläne dazu). Berücksichtigen Sie die Auswirkungen davon - Apple erstellt eine Plattform, auf der nur in Apple-Anwendungen erstellte Daten die höchste Sicherheitsstufe erhalten.

Beachten Sie auch, dass Sie (der Benutzer) nicht sehen können, was sich in diesen DataVaults befindet, ohne SIP zu deaktivieren. Es ist schwer zu sagen, was Apple in diesen hält, aber einige von ihnen sind ein bisschen alarmierend. Hier sind nur einige bekannte Datentresore:

~/Library/VoiceTrigger/SAT

~/Library/Containers/com.apple.mail/Data/DataVaults /private/var/folders/0z/fs4vdwmx6g31n69qt5v5ff580000gn/0/com.apple.nsurlsessiond

Das erste hat anscheinend "Siri Audio Transcripts" - alles, was Sie Siri jemals auf Ihrem Mac gesagt haben.

Ich habe kein Flag gefunden ~/Library/Containers/com.apple.mail/Data/DataVaultsund eine Neuinstallation von Mojave hat dazu geführt, dass das Verzeichnis seitdem nicht mehr angezeigt wird.

Eine zusammenfassende Übersicht über die Zugangskontrollen wurde ebenfalls veröffentlicht.


Sie können auch die Option rsync --ignore-error in Betracht ziehen.
Dave
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.