d345a4fcab
Die Ursache stand wörtlich im Protokoll von tccd: Prompting policy for hardened runtime; service: kTCCServiceCalendar requires entitlement com.apple.security.personal-information.calendars but it is missing Bei aktivierter Hardened Runtime verlangt TCC diese Entitlements auch ohne App-Sandbox. Die verbreitete Annahme, sie gälten nur für sandboxed Apps, ist falsch — und ich bin ihr aufgesessen. Ohne sie zeigt macOS den Dialog gar nicht erst an: die Anfrage kommt nach Millisekunden mit false zurück, der Status bleibt notDetermined, und die App taucht in den Systemeinstellungen nie auf. Dort lässt sich auch nichts nachtragen, der Kalenderbereich hat kein Pluszeichen — eine Sackgasse ohne jede Fehlermeldung. Gesetzt sind jetzt calendars, location, apple-events und audio-input, also alles, was Phase 3, 4 und 7 brauchen. Sie fehlen sonst genau dann, wenn das Feature fertig ist und niemand mehr an TCC denkt. Gefunden durch Ausschluss, nicht durch Nachdenken: eine minimale Test-App (normales Fenster, im Vordergrund, gleiches Zertifikat, nichts von Onyx darin) scheiterte identisch. Damit war belegt, dass es nicht an Onyx lag. Der Weg dorthin führte über mehrere falsche Fährten, die in docs/spikes/E-tcc-hardened-runtime.md stehen, damit sie niemand zweimal geht — darunter eine eigene: `log show` wurde von zsh abgefangen, und weil stderr umgeleitet war, sah die leere Ausgabe wie ein Befund aus. In der Praxis geprüft: Dialog erscheint, Zugriff erteilt, Status 3.
62 lines
2.7 KiB
XML
62 lines
2.7 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
|
<plist version="1.0">
|
|
<dict>
|
|
<!-- Bewusst KEIN com.apple.security.app-sandbox.
|
|
|
|
Die Calendarr-Integrationsanleitung fordert die Sandbox, aber sie ist
|
|
mit Onyx unvereinbar: eine sandboxed App kann keinen privilegierten
|
|
SMAppService-Daemon registrieren (kein Lüfter, kein Ladelimit), kommt
|
|
nicht an IOKit/IOReport (kein Hardware-Monitor) und kann /usr/bin/perl
|
|
nicht so starten, dass dessen MediaRemote-Entitlement noch greift.
|
|
|
|
Der App-Group-Container ist auf macOS unabhängig von der Sandbox, solange
|
|
beide Apps im selben Team signiert sind und die Group-ID mit dem
|
|
Team-Präfix beginnt. Nachgemessen in docs/spikes/D-appgroup.md. -->
|
|
|
|
<key>com.apple.security.application-groups</key>
|
|
<array>
|
|
<string>PP34X97WS3.group.com.scarriffleservices.calendarr</string>
|
|
</array>
|
|
|
|
<!-- Das mitgelieferte MediaRemoteAdapter.framework ist ad-hoc signiert,
|
|
der Host mit Team-Zertifikat. Ohne das wird es nicht geladen. -->
|
|
<key>com.apple.security.cs.disable-library-validation</key>
|
|
<true/>
|
|
|
|
<!-- Bei aktivierter Hardened Runtime verlangt TCC diese Entitlements —
|
|
auch ohne Sandbox. Das ist die verbreitete Fehlannahme: sie gelten
|
|
nicht nur für sandboxed Apps.
|
|
|
|
Fehlt eine davon, weigert sich macOS, den Berechtigungsdialog
|
|
überhaupt anzuzeigen. Die Anfrage kommt kommentarlos mit `false`
|
|
zurück, der Status bleibt `notDetermined`, und die App taucht in den
|
|
Systemeinstellungen nie auf — dort lässt sich auch nichts von Hand
|
|
nachtragen. Der Grund steht ausschließlich im Protokoll von tccd:
|
|
|
|
"Prompting policy for hardened runtime; service: kTCCServiceCalendar
|
|
requires entitlement com.apple.security.personal-information.calendars
|
|
but it is missing"
|
|
|
|
Nachgemessen mit einer minimalen Test-App: ohne die Entitlement kein
|
|
Dialog, mit ihr sofort. -->
|
|
|
|
<!-- Kalender-Widget (Phase 3) -->
|
|
<key>com.apple.security.personal-information.calendars</key>
|
|
<true/>
|
|
|
|
<!-- Wetter am aktuellen Standort (Phase 3) -->
|
|
<key>com.apple.security.personal-information.location</key>
|
|
<true/>
|
|
|
|
<!-- AppleScript-Rückfall für Spotify und Musik (Phase 4) -->
|
|
<key>com.apple.security.automation.apple-events</key>
|
|
<true/>
|
|
|
|
<!-- Per-App-Lautstärke über Core-Audio-Taps (Phase 7). Aufgezeichnet wird
|
|
nichts; die Berechtigung heißt nur so. -->
|
|
<key>com.apple.security.device.audio-input</key>
|
|
<true/>
|
|
</dict>
|
|
</plist>
|