The subsystem that tracks these permissions is known as TCC (short for transparency, consent, control). It is quite complex and it’s certainly had its fair share of bugs over the years )-:
So far a restart has immediately fixed it every time.
The next time this crops up try using tccutil to reset the relevant service. It probably won’t help — the reset is most helpful with persistent problems rather than these transient ones — but it’s worth a shot.
For details on the comand, see tccutil man page. Unfortunately that doesn’t include a list of services. For that, see my posts on this thread.
I'd be interested to learn how macos actually adds a binary to the
permissions list.
It’s, as I said, complex (-: The two basic steps are:
-
Find the responsible code for the process (something I touch on here).
-
Get and store that code’s designated requirement (see Code Requirements in the Code Signing Guide).
However, this process is complicated by a whole world of edge cases. For example, what happens if the code isn’t signed? Or is signed ad hoc and thus doesn’t have a DR?
The one critical step that you can take to avoid TCC problems is to make sure that your code is signed with a stable DR, such that build N+1 of your code has the same DR as build N. Any standard signing identity issued by Apple will give you this.
You can dump dump an executable’s DR using codesign:
% codesign -d -r - /Applications/QProcessDock.app
Executable=/Applications/QProcessDock.app/Contents/MacOS/QProcessDock
designated => anchor apple generic and identifier "com.example.apple-samplecode.QProcessDock" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = SKMME9E2Y8)
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
