Filesystem privileges in an unsigned app (not signed at all)

I have a general question about unsigned apps and privileges for accessing folders like ~/Documents, ~/Desktop, ~/Downloads, and removable volumes. Note that these correspond to the Info.plist keys NSDesktopFolderUsageDescription, NSDocumentsFolderUsageDescription, NSDownloadsFolderUsageDescription, NSRemovableVolumesUsageDescription for the app.

This question is for an app that has no codesigning whatsoever -- not even ad-hoc. If i ad-hoc codesign the app, the problem goes away and i can do everything normally. The question is about whether i actually need to do that or if unsigned apps are supposed to allow such operations on Mac OS X.

If i build an app on my machine and i want to access files in these folders in a way that doesn't go through an explicit GUI prompt, does the app have to be codesigned? I am confident when i first built this app, it prompted me for access to each of these locations when i first needed access, and i was able to operate the application normally to access files without a gui "Open File" dialog.

However, when i recently upgraded the app, i started to get errors. When i check the console, it seems these are mainly problems with the tccd (Daemon for the Transparency, Consent, and Control Subsystem) when the app launches. This is followed by errors with sandboxd when the app actually tries to do the access.

The specific errors from tccd are:

Failed to copy signing info for 710, responsible for file:///Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs: #-67062: Error Domain=NSOSStatusErrorDomain Code=-67062 "(null)"

and

internal_TCCCreateDesignatedRequirementIdentityFromMessage: Refusing TCCCreateDesignatedRequirementIdentityFromAuditToken (kTCCServiceAppleEvents) accessing={identifier=<ID of InvalidCode>, pid=710, auid=503, euid=503, binary_path=/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs}, requesting={identifier=com.apple.appleeventsd, pid=332, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd}, : unable to compute designated requirement for: file:///Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs.,

and

identifier=<ID of InvalidCode>, pid=710, auid=503, euid=503, binary_path=/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs attempted to call TCCAccessRequest for kTCCServiceAccessibility without the recommended com.apple.private.tcc.manager.check-by-audit-token entitlement

and

os_unix.c:44580: (2) open(/var/db/DetachedSignatures) - No such file or directory

and (from sandboxd)

System Policy: Emacs(710) deny(1) file-read-data ...<more>

As you can tell by the errors, i happen to be using an Emacs.app built from macports. This port i am using is the emacs-app-devel subport which builds from the emacs git sourcetree, but i do not think that is all too relevant here.
The answer here is that you should sign your code. Unsigned code runs into all sorts of edge cases. I’ve not looked into these TCC checks specifically but, given your description, it seems that they’re just a new pitfall in a long sequence of pitfalls encountered by unsigned code.

IMPORTANT Unsigned code won’t even run on Apple silicon Macs, so it’s worthwhile sorting this out sooner rather than later.

You can sign your code ad-hoc (“Sign to run locally” in Xcode parlance) by adding the -adhoc_codesign linker flag. This is the default for Apple silicon builds but you have to opt in to it on Intel.

Oh, one more thing: Ad-hoc code signing won’t really fix your TCC problem. It gives TCC a handle by which to identify your program but that handle isn’t stable. Every time you rebuild, the program get a different signature and TCC thinks it’s a different program. To work well with TCC you need to sign your code with a stable identity, typically an Apple-issued code signing identity.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Filesystem privileges in an unsigned app (not signed at all)
 
 
Q