How to reset system's assessment of an app's container access

Due to changes in macOS 15 Sequoia with respect to container privacy/privileges, I have observed warnings with one of my apps (non-sandboxed) when its subsidiary crash reporter process tries to access the host app's data folder.

I THINK I've worked around this issue by granting the crash reporter and the host app access to the same application group. I'm not 100% sure how all this works except that the problem went away :)

The problem is, once the problem goes away on a given system, it goes away for good! Even with subsequent attempts to open a version of the app before the fix was in place, the system warning is not presented. I've tried to reset SystemPolicyAppBundles on the app via tccutil, but it makes no difference.

Using the wisdom from one of Quinn's posts (https://developer.apple.com/forums/thread/706442) I set up a log stream invocation to try to gather clues, and I notice that when I launch my app now, I see messages like:

Found provenance data on process: TA(82542d1beaf132a6, 2), 51084 Process was already in provenance sandbox, skipping: 51084, TA(82542d1beaf132a6, 2)

I suspect this "provenance" may reflect the change in how the system treats my application.

First: I wonder if it's a bug that any change in "provenance" should retroactively apply to versions of the app before the change was made. Second, I wonder if there's some way to RESET this provenance so that I can reproduce the bug again? I might be able to reproduce it by changing the bundle ID for the app but for purposes of testing against existing, shipped versions of the app, I'd love to be able to reset things for sanity-checking.

Answered by DTS Engineer in 795111022
I'll try it in a VM first...

That’s the approach I recommend. See Testing a Notarised Product for an example of the process I use.

I’ve seen a lot of folks suggest a lot of hacky solutions to problems like this. Frankly, I’m not a fan of those because they make it hard to tell whether the behaviour you’re seeing is what your users will see or just an artefact of your hackery.

Ripley I say we take off and nu‍ke the entire site from orbit.

[dramatic pause]

Ripley It’s the only way to be sure.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have discovered a system database at:

/var/db/SystemPolicyConfiguration/ExecPolicy

Which seems to contain the pertinent provenance information. I am hoping there is a command line tool that will reset values in this database so that I don't have to go wild and try hacking the file myself. But this gives me a lead at least! I'll try it in a VM first...

Accepted Answer
I'll try it in a VM first...

That’s the approach I recommend. See Testing a Notarised Product for an example of the process I use.

I’ve seen a lot of folks suggest a lot of hacky solutions to problems like this. Frankly, I’m not a fan of those because they make it hard to tell whether the behaviour you’re seeing is what your users will see or just an artefact of your hackery.

Ripley I say we take off and nu‍ke the entire site from orbit.

[dramatic pause]

Ripley It’s the only way to be sure.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

How to reset system's assessment of an app's container access
 
 
Q