macOS 27 verweigert teamübergreifenden Container-Zugriff ohne Nachfrage

Unter macOS liefert containerURL(forSecurityApplicationGroupIdentifier:) eine plausibel aussehende URL, selbst für eine App Group, für die Sie keinerlei Berechtigung besitzen. Apple dokumentiert das unmissverständlich: Unter iOS gibt die Methode nil zurück, wenn der Bezeichner ungültig ist; unter macOS dagegen wird „stets eine URL der erwarteten Form zurückgegeben, selbst wenn die App Group ungültig ist”.⁴ In macOS 27 kollidiert dieses Verhalten mit einer neuen Einschränkung.

macOS 27 fragt den Benutzer nicht mehr, bevor es teamübergreifenden Container-Zugriff verweigert. Wer Dateien im App-Datencontainer oder App-Group-Container eines anderen Entwicklerteams las, löste früher eine Berechtigungsabfrage aus. Heute schlägt der Zugriff standardmäßig fehl und lässt sich nur wiederherstellen, wenn der Benutzer den Eintrag unter „Datenschutz & Sicherheit” findet.¹

Aus diesen beiden Tatsachen setzt sich ein Fehler zusammen, der genau an der Stelle des Scheiterns kein Signal gibt. Kein Dialog erscheint. Die Methode liefert eine URL statt nil. Der Pfad sieht exakt so aus, wie Sie ihn erwartet haben. Die Verweigerung zeigt sich erst später, beim Dateizugriff — und dort liest sie sich wie eine fehlende Datei.

TL;DR

macOS 27 entfernt die Berechtigungsabfrage für den Zugriff auf App-Daten- und App-Group-Container fremder Teams und verweigert solche Zugriffe standardmäßig; die Kontrolle darüber liegt nun in den Einstellungen unter „Datenschutz & Sicherheit”.¹ Verbucht ist die Änderung unter System Integrity Protection als neue Funktion, nicht als Fehlerbehebung. Apples eigene Anleitung zu App-Group-Containern beschreibt weiterhin genau das Abfrageverhalten, das macOS 27 abgeschafft hat. Weil die macOS-API selbst für unerreichbare Gruppen eine wohlgeformte URL liefert, taucht die Verweigerung erst beim Lesen auf und nicht beim Aufruf der API. Zugriffe innerhalb desselben Teams bleiben unberührt: Die Grenze verläuft entlang der Team ID.

Was sich geändert hat

Die Versionshinweise zu macOS 27 enthalten unter System Integrity Protection einen einzigen Satz:¹

„Der Zugriff auf Dateien in App-Datencontainern und App-Group-Containern anderer Entwicklerteams fragt den Benutzer nicht länger um Autorisierung; solche Zugriffe werden standardmäßig verweigert und lassen sich vom Benutzer in den Einstellungen unter ‚Datenschutz & Sicherheit’ verwalten.”

Radar 161835690. Zwei Teilsätze, zwei getrennte Änderungen.

Der erste Teilsatz beseitigt eine Abfrage. Der zweite macht die Verweigerung zum Standard. Die Berichterstattung stellt meist die Verweigerung nach vorn — die uninteressantere Hälfte. Verschärfte Standardwerte sind Routine. Eine verschwundene Abfrage dagegen verändert die Gestalt des Fehlers, den Ihre Benutzer erleben, und damit auch die Gestalt des Fehlerberichts, der bei Ihnen eintrifft.

Früher sah ein Benutzer einen Dialog und traf eine Entscheidung. Bei einer Ablehnung wusste Ihre App, dass ein Mensch sich so entschieden hatte. Heute wird niemand mehr gefragt. Der Zugriff findet schlicht nicht statt, und der einzige Weg, ihn zu erlauben, führt über einen Einstellungsbereich, den der Benutzer aus eigenem Antrieb nie öffnen würde.

Das frühere Verhalten, das Apples Dokumentation weiterhin beschreibt

Die Einschränkung setzt auf einem Schutz auf, der zwei Versionen zuvor eingeführt wurde. Apples Leitfaden zu App-Group-Containern hält fest:²

„Ab macOS 15 bieten App-Group-Container [System Integrity Protection] für die lokalen Dateien Ihrer App, selbst wenn die App nicht über die App-Sandbox-Fähigkeit verfügt. Diese App-Group-Container beschränken den Zugriff durch Apps, die nicht zur App Group gehören. Versuchen Apps außerhalb der App Group, auf Orte innerhalb einer App Group oder eines App-Datencontainers zuzugreifen, führt das zu einer Abfrage, die den Benutzer um Autorisierung bittet.”

Diese Seite beschreibt die Abfrage im Präsens. Zum Zeitpunkt dieses Textes hat Apple sie nicht an macOS 27 angepasst.

Die praktische Folge: Wer über das Problem stolpert, die Dokumentation durchsucht und auf die offizielle Seite stößt, bekommt dort gesagt, es erscheine ein Berechtigungsdialog. Der erscheint aber nicht. Naheliegend ist dann der Schluss, die Abfrage sei kaputt oder die eigenen Berechtigungen seien falsch konfiguriert — und die Suche läuft an der falschen Stelle weiter.

Prüfen Sie den Stand dieser Seite lieber selbst, statt sich auf das Datum dieses Beitrags zu verlassen. Dokumentation holt irgendwann auf.

Warum der Fehler zu spät auftaucht

Erst das Verhalten der API macht aus einer Richtlinienänderung ein Debugging-Problem.

Apples Referenz zu containerURL(forSecurityApplicationGroupIdentifier:) benennt den Unterschied zwischen den Plattformen ausdrücklich:⁴

„Eine URL, die auf den gemeinsamen Ordner der Gruppe im Dateisystem verweist. Unter iOS ist der Wert nil, wenn der Gruppenbezeichner ungültig ist. Unter macOS wird stets eine URL der erwarteten Form zurückgegeben, selbst wenn die App Group ungültig ist; prüfen Sie deshalb unbedingt, ob Sie auf den zugrunde liegenden Ordner zugreifen können, bevor Sie ihn verwenden.”

Der Diskussionsabschnitt wiederholt die Warnung: Ein Aufruf mit einem Gruppenbezeichner, für den keine Berechtigung vorliegt, liefert trotzdem eine URL der erwarteten Form — nur existiert der Ordner nicht, und eine App in der Sandbox kann ihn nicht anlegen.⁴

Das übliche defensive Muster nützt hier also nichts:

// This guard passes on macOS regardless of entitlement.
guard let url = FileManager.default.containerURL(
    forSecurityApplicationGroupIdentifier: "ABCDE12345.com.example.shared"
) else {
    return  // never taken on macOS
}

Die URL ist wohlgeformt. Sie zeigt auf ~/Library/Group Containers/<team>.<group> — genau dorthin, wo dieser Container liegen würde. Alles wirkt wie ein Erfolg, bis eine Dateioperation darauf trifft.

Die Lösung besteht darin, den Lesezugriff zu versuchen und den Fehler zu behandeln, statt vorab zu fragen, ob er gelingen würde:

let fm = FileManager.default
guard let url = fm.containerURL(
    forSecurityApplicationGroupIdentifier: groupID
) else { return }  // macOS never takes this branch

do {
    _ = try fm.contentsOfDirectory(atPath: url.path)
    // Reached the container.
} catch {
    // On macOS 27 a cross-team denial lands here.
    // No prompt fired. The user was never asked.
    presentContainerUnavailable(error)
}

Widerstehen Sie der Versuchung, isReadableFile(atPath:) als Vorabprüfung einzusetzen. Apple rät von dieser ganzen Art von Test ab:³

„Es empfiehlt sich nicht, Verhalten vom aktuellen Zustand des Dateisystems oder einer bestimmten Datei abhängig zu machen. Das kann zu seltsamem Verhalten oder zu Race Conditions führen. Weit besser ist es, eine Operation zu versuchen (etwa eine Datei zu laden oder einen Ordner anzulegen), auf Fehler zu prüfen und diese Fehler sauber zu behandeln, als im Voraus herausfinden zu wollen, ob die Operation gelingen wird.”

Für diese Änderung kommt ein zweiter Grund hinzu. Dieselbe Seite hält fest, dass isReadableFile(atPath:) „die reale Benutzer- und Gruppen-ID” heranzieht, um die Lesbarkeit zu bestimmen.³ Das ist eine Auswertung von POSIX-Rechten. Die Verweigerung eines teamfremden Containers ist dagegen eine Richtlinienentscheidung oberhalb von POSIX — eine Prüfung der Rechtebits bildet sie nicht zwangsläufig ab. Eine Vorabprüfung, die true zurückgibt, bevor der Lesezugriff dann doch scheitert, ist schlimmer als gar keine: Sie schiebt die Überraschung noch weiter von ihrer Ursache weg.

Wer canOpenURL ist in iOS 27 veraltet gelesen hat, erkennt das Muster wieder. Apple nimmt Schritt für Schritt die Möglichkeit, vorher zu fragen, und lässt Ihnen die Möglichkeit, es zu versuchen. Versuchen-und-behandeln wird zur allgemeinen Antwort, nicht zum Notbehelf für eine einzelne API.

Beachten Sie die Asymmetrie zwischen den Plattformen. iOS gibt nil zurück und scheitert ehrlich an der Aufrufstelle. macOS gibt eine URL zurück und vertagt das Scheitern. Die Änderung in macOS 27 entfernt nun die Abfrage — das letzte verbliebene Signal auf jener Plattform, die ohnehin schon die leisere von beiden war.

Noch eine Falle: Apple empfiehlt, immer die von dieser Methode gelieferte URL zu verwenden, statt ~/Library/Group Containers/... von Hand zusammenzusetzen, denn der Ort kann sich in künftigen Versionen ändern.⁴ Wer diesen Pfad fest verdrahtet hat, besitzt überhaupt keinen Methodenaufruf zum Prüfen — und keine Stelle, an der die Lesbarkeitsprüfung stehen könnte.

Wahrscheinlich nicht an das SDK gebunden

Naheliegend ist die Frage, ob ein älteres SDK die Änderung hinauszögert. Die Versionshinweise schweigen dazu.

Erkennbar ist allerdings ein Muster. In elf einzelnen Einträgen verwenden die Hinweise zu macOS 27 ausdrücklich SDK-abhängige Formulierungen: „In Apps, die mit dem macOS-27.0-SDK gebaut wurden”, „In Apps, die mit den 27.0-SDKs gebaut wurden”, „Wenn Ihr Projekt ein Mindest-Deployment-Target unterhalb von 27.0 hat”.¹ Apple schränkt solche Änderungen also ein, wo die Einschränkung zutrifft.

Der Eintrag zu den Containern trägt keine derartige Einschränkung. Liest man dieses Fehlen als beabsichtigt — und das ist die naheliegende Lesart —, dann handelt es sich um eine Richtlinie auf Systemebene, die für jedes unter macOS 27 laufende Binary gilt, unabhängig davon, mit welchem SDK es gebaut wurde.

Behandeln Sie das als starke Schlussfolgerung und nicht als Tatsachenbehauptung, denn Apple sagt es nirgends direkt. Praktisch läuft es ohnehin auf dasselbe hinaus: Verlassen Sie sich nicht auf ein älteres SDK als Gegenmaßnahme. Rechnen Sie damit, dass der Zugriff scheitert.

Wen es tatsächlich trifft

Zugriffe innerhalb desselben Teams bleiben unangetastet. Apples Regeln machen die Grenze entlang der Team ID zu etwas Strukturellem statt Zufälligem: „Verschiedene Entwicklerteams können nicht dieselbe App Group verwenden”, während ein einzelnes Team eine Gruppe über seine eigenen Apps und Hilfsprozesse hinweg teilen darf.²

Kaputt gehen also die Apps, die über diese Linie greifen:

Migrations- und Importwerkzeuge. Alles, was den Container eines Konkurrenz- oder Vorgängerprodukts liest, um Benutzerdaten zu übernehmen. Das ist der klarste Fall — und er hing schon bisher an einer Abfrage, die Benutzer manchmal bestätigt haben.

Backup- und Sync-Werkzeuge. Programme, die App-Container zur Sicherung durchgehen, überspringen nun stillschweigend alles, was außerhalb des eigenen Teams liegt.

Begleit-Apps, die den Besitzer gewechselt haben. Der schärfste Fall, denn am Code ändert sich nichts. Zwei Apps erscheinen unter einer Team ID und teilen sich anstandslos eine Gruppe. Eine Übernahme, eine Teamaufspaltung oder der Umzug auf ein eigenes Entwicklerkonto stellt sie unter verschiedene Team IDs. Der App-Group-Bezeichner sieht weiterhin richtig aus, die URL löst weiterhin auf — und die Daten kommen nicht mehr an.

Bei diesem letzten Fall lohnt es sich zu verweilen, denn der Zeitpunkt arbeitet gegen Sie. Änderungen an der Team ID erledigt, wer Signierung und Distribution verwaltet — und von dort aus ist die Abhängigkeit vom gemeinsamen Container in aller Regel unsichtbar. Der Code kompiliert. Beide Apps gehen raus. Keine der beiden Testsuiten schlägt an, weil Unit-Tests keinen echten teamfremden Container anfassen und die CI beide Targets unter derjenigen Identität baut, die der Build-Rechner gerade hält. Der Fehler taucht in Produktion auf, auf den Rechnern der Benutzer, als Daten, die zwischen zwei Apps nicht mehr synchronisiert werden — zwei Apps, die ein Benutzer mit gutem Grund für dasselbe Produkt hält.

Planen Sie eine Migration der Team ID, ist die Prüfung rein mechanisch: Suchen Sie per grep jeden App-Group-Bezeichner, den Ihre Targets deklarieren, und listen Sie zu jedem auf, welche Bundles ihn lesen. Jeder Bezeichner, der von Bundles gelesen wird, die künftig unter verschiedenen Team IDs liegen, bricht. Vor dem Umzug ist das eine Prüfung von zehn Minuten, danach ein Support-Vorfall.

Apple zählt auf, was an App Groups teilnehmen kann: Hauptprogramme in Bundle-Strukturen, App Extensions, App Clips und XPC Services.² An jeder dieser Stellen kann das Problem auftauchen.

Diagnose

Zwei Prüfungen lohnen sich, bevor Sie einen Fehler im eigenen Code annehmen.

Vergewissern Sie sich zunächst, dass das System Ihre Berechtigungen überhaupt validiert hat. Apple dokumentiert dafür eine Laufzeitprüfung des Flags „entitlements validated” an einem laufenden Prozess:²

sudo launchctl procinfo <pid>

Provisioning Profiles aus der Zeit vor der App-Group-Autorisierung enthalten diese womöglich nicht — und erzeugen dann Zugriffsfehler, die der Verweigerung unter macOS 27 zum Verwechseln ähnlich sehen, aber eine andere Ursache haben. Xcode erneuert die Profile, wenn „Automatically manage signing” aktiv ist und die Build-Einstellung REGISTER_APP_GROUPS auf Yes steht.²

Machen Sie sich außerdem klar, welche Form des Bezeichners Sie verwenden. Gruppen mit dem Präfix group. müssen im Provisioning Profile der App enthalten sein. Gruppen in der Form <TeamID>.<group name> brauchen kein Profil, weil das System das Team-Präfix gegen die Signatur-Identität prüft; diese Form gibt es allerdings nur unter macOS, und Keychain Access Groups unterstützen sie nicht.²

Prüfen Sie danach „Datenschutz & Sicherheit”, denn dort liegt laut Versionshinweis nun die Kontrolle des Benutzers.¹

Entwerfen für eine Verweigerung, die sich nicht abfragen lässt

Die Abfrage hat Produktarbeit geleistet, nicht bloß Sicherheitsarbeit. Sie hat dem Benutzer mitgeteilt, dass es überhaupt eine Entscheidung gibt, und Ihrer App mitgeteilt, wann eine getroffen wurde. Beide Aufgaben fallen jetzt Ihnen zu.

Testen Sie an der Grenze — einmal. Setzen Sie einen einzigen, möglichst kleinen Lesezugriff ab, sobald Sie den Container zum ersten Mal auflösen, statt die Verweigerung mitten in einer Sync-Schleife zu entdecken. Ein Fehler tief in einer Warteschlange liefert ein unvollständiges Ergebnis und einen Fehler, der ausgerechnet der Datei zugeschrieben wird, die zufällig als Nächstes an der Reihe war. Ein einziger Versuch an der Stelle der Auflösung gibt Ihnen genau einen Punkt zum Verzweigen — und anders als eine Rechteprüfung im Voraus geht er denselben Weg, den Ihre echten Lesezugriffe nehmen werden.

Sagen Sie in der Sprache des Benutzers, was passiert ist. „Daten konnten nicht gelesen werden” lädt zu einem Support-Ticket über Datenverlust ein. Die zutreffende Meldung benennt die Grenze und den Ausweg: Die Daten gehören zu einer App eines anderen Entwicklers, macOS blockiert diesen Zugriff standardmäßig, und der Schalter dafür liegt unter „Datenschutz & Sicherheit”. Auf einen Fehler, den man nicht verorten kann, lässt sich nicht reagieren.

Wiederholen Sie den Versuch nicht. Eine Verweigerung ist ein Richtlinienzustand, kein vorübergehender Fehler. Backoff-Schleifen gegen einen blockierten Container verbrauchen Akku und füllen Logs, ohne irgendetwas zu ändern. Scheitern Sie einmal, machen Sie den Zustand sichtbar und bieten Sie eine erneute Prüfung an, die der Benutzer nach dem Ändern der Einstellung selbst auslösen kann.

Prüfen Sie bei Aktivierung erneut, statt in festen Intervallen abzufragen. Wenn der Benutzer die App verlässt, um eine Einstellung zu ändern, und zurückkehrt, ist das der Moment für einen neuen Zugriffsversuch. Ein blockierter Pfad, den ein Timer abfragt, liefert dieselbe Verweigerung — nur eben im gewählten Intervall.

Fragen Sie sich, ob Sie den teamübergreifenden Lesezugriff überhaupt brauchen. Das ist die unbequeme Frage — und oft die richtige Antwort. Ein Migrationswerkzeug, das den Container eines Konkurrenten liest, tut etwas, das die Plattform seit drei Versionen einengt: in macOS 15 in die Sandbox gesteckt, dann abgefragt, jetzt verweigert. Ein Exportweg, den die andere App kontrolliert, ein dokumentbasierter Import über eine vom Benutzer gesteuerte Dateiauswahl oder ein dokumentiertes Austauschformat überleben diese Änderung allesamt. Container-Lesezugriffe über eine Team-ID-Grenze hinweg folgen einer Entwicklungslinie, und diese Linie zeigt nur in eine Richtung.

Die Dateiauswahl verdient eine eigene Erwähnung, denn sie ist der Ausweg, den die Plattform vorsieht. Wählt jemand eine Datei aus, wird der Zugriff ausdrücklich über den Security-Scoped-Mechanismus erteilt — ein tragfähigeres Berechtigungsmodell als die gerade verschwundene Abfrage, und es greift schon heute, ganz ohne Änderung an den Einstellungen.

Die wichtigsten Punkte

Für macOS-App-Entwickler: - Werten Sie unter macOS einen Rückgabewert von containerURL(forSecurityApplicationGroupIdentifier:) ungleich nil niemals als Beleg für Zugriff. Die Methode liefert immer eine URL. Versuchen Sie den Lesezugriff und behandeln Sie den Fehler. - Verzichten Sie auf isReadableFile(atPath:) als Vorabprüfung. Apple rät davon ab, Ergebnisse des Dateisystems vorherzusagen, und die Methode wertet POSIX-Rechte aus, die eine Verweigerung auf Richtlinienebene gar nicht berühren muss. - Prüfen Sie jeden Codepfad, der einen Container unter einer anderen Team ID liest. Unter macOS 27 scheitert er, ohne dass irgendjemand gefragt wird. - Wer ~/Library/Group Containers/... fest verdrahtet hat, besitzt keinen Methodenaufruf zum Absichern. Wechseln Sie zur API, damit die Prüfung überhaupt einen Ort hat.

Für Teams, die Migrations- oder Backup-Werkzeuge ausliefern: - Teamübergreifende Lesezugriffe hängen nicht mehr an einer Abfrage, die der Benutzer bestätigen könnte. Planen Sie die Verweigerung als Normalzustand ein und sagen Sie Ihren Benutzern, wo die Einstellung liegt. - Der Fehler zeigt sich als fehlende Daten, nicht als Fehlermeldung. Formulieren Sie eine ausdrückliche Meldung, sonst melden Benutzer den Vorfall als Datenverlust.

Für alle, die ihre Team ID ändern: - Eine Übernahme oder eine Kontoaufteilung kappt stillschweigend die gemeinsame Nutzung von App Groups zwischen Apps, die zuvor dasselbe Team-ID-Präfix hatten. Im Quellcode weist nichts darauf hin.

FAQ

Betrifft das auch Apps, die sich innerhalb eines Entwicklerkontos einen Container teilen?

Nein. Die Grenze verläuft entlang der Team ID. Apples Regeln verhindern ohnehin, dass verschiedene Teams dieselbe App Group verwenden, und ein einzelnes Team darf eine Gruppe über seine eigenen Apps, Extensions, App Clips und XPC Services hinweg teilen.²

Sehen meine Benutzer eine Abfrage, die sie bestätigen können?

Unter macOS 27 nicht. Der Versionshinweis stellt fest, dass solche Zugriffe keine Autorisierungsabfrage mehr auslösen und standardmäßig verweigert werden; verwaltet werden sie nun in den Einstellungen unter „Datenschutz & Sicherheit”.¹

Kann ich das umgehen, indem ich gegen ein älteres SDK baue?

Wahrscheinlich nicht. Die Versionshinweise verwenden für elf andere Änderungen ausdrücklich SDK-abhängige Formulierungen, für diese jedoch keine — was für eine Richtlinie auf Systemebene spricht, die für sämtliche Binaries gilt.¹ Apple sagt es nicht direkt, behandeln Sie es also als starke Schlussfolgerung und rechnen Sie damit, dass der Zugriff scheitert.

Wie unterscheide ich das von einem Provisioning-Problem?

Führen Sie sudo launchctl procinfo <pid> aus und prüfen Sie, ob das System für Ihren Prozess das Flag „entitlements validated” gesetzt hat. Ältere Provisioning Profiles können aus der Zeit vor der App-Group-Autorisierung stammen und einen sehr ähnlich aussehenden Fehler mit völlig anderer Ursache erzeugen.²

Warum beschreibt die Dokumentation weiterhin eine Abfrage?

Apples Leitfaden zu App-Group-Containern beschreibt das Verhalten von macOS 15 und war zum Zeitpunkt dieses Textes nicht an die Änderung in macOS 27 angepasst.² Prüfen Sie den aktuellen Stand dieser Seite, statt sich auf das Datum dieses Beitrags zu verlassen.

Quellen