Device Authorization in a C-Tool

When starting this tool indirectly from another application

Please clarify what you mean by “indirectly” here. Is your tool embedded within this app? Also, when you start it, does it end up being a child process of the app?

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

"Indirectly" means, that this C-tool is just a temporary running helper application, which is launched by a main application using fork() and execve(). If I launch the tool instead standalone from XCode or from command line, the authorization dialog appears.

This is not my first tool I attached this way. But the other tools "only" need access to the harddisk, which successfully brings up the authorization dialog, even when launched from main application.

I did some further investigations:

• When adding a file operation prior to the camera access the authorization dialog for file access comes up but app still quits at camera access.
• I removed the complete TCC.db -> no changes, same behaviour as described above.
• I made a complete new XCode project in XCode 13

Now:

• Console shows this message:

"Termination Reason: Namespace TCC, Code 0 This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCameraUsageDescription key with a string value explaining to the user how the app uses this data."

• The info dictionary in main bundle at time of camera access does not contain NSCameraUsageDescription key as provided in Info.plist. Was present when launching XCode12.2.-project and is present in Info.plist file of project.

• The main bundle has no bundleIdentifier in runtime any more. Dont know whats going on...

In my oppinion the whole authorization stuff is a big mess. Cant be that difficult to implement a working default mechanism instead of terminating the app without visible hint of reason. I also do expect a suitable solution from an 21st century development environment to produce files like Info.plist by itself. This is awful, arghhh!!

Looks if the Info.plist used by the app is not the Info.plist from file. So where does ist come from ? Please tell me whats the correct way of adding Info.plist to the XCode.project.

Looks if the Info.plist used by the app is not the Info.plist from file.

Right. Xcode 13 reworked the default way that it manages your app’s Info.plist. For typical projects the Info.plist is constructed by Xcode based on your build settings. This means that there’s no longer any Info.plist file on disk.

If you want to stick with the Xcode 13 model, which is what I recommend, go to the Info tab of the target editor and add NSCameraUsageDescription to the Custom macOS Application Target Properties list. This gets mirrored to the INFOPLIST_KEY_NSCameraUsageDescription build setting which Xcode rolls into the Info.plist file that it constructs during the build process.

If you want to stick with the legacy model, make sure that Generate Info.plist File (GENERATE_INFOPLIST_FILE) is off and then configure your Info.plist file as you did previously. I know this works because I exercise it every day (-: [1]

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

[1] I have a custom template that I use for all my new projects and I’ve not updated it to use the new system )-:

Thanks for the advice. Info.plist works now. :-) But doesnt solve the problem...

In meantime I found the reason why the authorization dialog doesnt appear. More by accident than by intention I edited the Info.plist of the main application instead of the Info.plist of the helper app. Surprisingly, it works now. That means it is necessary to provide the main application with the NSCameraUsageKey and NSMicrophoneUsageKey, too. Looks as if the newly created process for the helper app is not detached completely from the calling process of the main app...

Looks as if the newly created process for the helper app is not detached completely from the calling process of the main app

Ah, um, such a detachment is exactly what we’re trying to avoid. TCC works hard to find the responsible code for any given privacy prompt, for reasons I explain, in a different context, in my On File System Permissions post.

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