On MacOS 12.0 (Monterey), no attempt to use tccutil (with sudo or otherwise) works. All cases returned an error:
mbp16inch2021:/ Stephen$ sudo tccutil reset com.mycompany.AppName tccutil: Failed to reset com.mycompany.App
mbp16inch2021:/ Stephen$ tccutil reset AppName tccutil: Failed to reset AppName
DTS confirmed it didn't work for them, too. I'm about to submit a bug, but maybe I have the syntax incorrect?
The examples you posted suggest your ‘holding it wrong’. Consider this:
% tccutil
tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]
You have to start with the TCC service you’re trying to reset, not the app name or bundle ID.
IMPORTANT There’s no good way to get a list of valid services. I’ve posted a list to this thread. If you see something missing from that list, ping me over there and I’ll update the list.
DTS confirmed it didn't work for them, too.
I didn’t see that go by. Please email me the ticket number you got so that I can find out why. My email address is in my signature. Make sure to include a reference to this DevForums thread for context.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Quinn, so YOU WERE CORRECT -- I needed to add the SERVICE. DTS must have missed that, too. I will also email you the ticket number.
HOWEVER, I'm suspect that "Accessibility" is perhaps NOT the right service, because resetting Accessibility did NOT reset the Files and Folders settings for the app or bundle ID.
We are trying to reset this tcc data: if the user UNCHECKS an allowed folder for an application (say "Documents"), subsequent attempts to use POSIX open() on a file inside that folder will NO LONGER present the system alert: " would like to access files in your Documents folder" (OK / Don't Allow)
This has become a problem, because unlike the first access attempt which DOES ask that question, open() gets an exception with POSIX error 1 "unable to open that document -- operation not permitted".
So I'm sure you're thinking: why would the user actually uncheck the Documents folder access permission? The answer is that they DON'T -- this appears to be some sort of bug in Big Sur, where an Apple pushed Big Sur update somehow disrupts the already-approved permission of the Documents folder for our application. So we're trying to fix that so MacOS will just re-ask for access as if it never knew anything about the Application's previous permissions.
...which is why we're trying to reset that information in the tcc.
Stephen
I will also email you the ticket number.
Thanks. I’ll respond to your email later today but I’m going to keep the TCC discussion going here.
resetting Accessibility did NOT reset the Files and Folders settings for the app or bundle ID.
Indeed. As promised, I updated the other thread with a list of services related to Files and Folders
We are trying to reset this tcc data: if the user UNCHECKS an allowed folder for an application (say
Documents), subsequent attempts to use POSIXopenon a file inside that folder will NO LONGER present the system alert
Right. Unchecking that box is an explicit user action that withdraws consent.
So we're trying to fix that so MacOS will just re-ask for access as if it never knew anything about the application's previous permissions.
Be very careful here. If apps start using tccutil as a mechanism to nag users to consent to an action, it’s easy to imagine this feature being removed from the system.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Quinn,
You were exactly correct (as usual). SystemPolicyDocumentsFolder was the proper service name for tccutil.
And -- you're also wise to caution us against continual use of tccutil.
But here's what we're facing (mentioned here in case other devs stumble onto this issue): With approximately .5% of our users, we've observed a problem that mostly seems to her with Big Sur, where after the user has granted access, usually by explicitly opening a file (or several() inside a folder that is inside the Documents folder, at some point, usually after a MacOS system or security update, the tcc database gets messed up, and the app's previous permissions are "forgotten". As best we can tell, the Documents checkbox in Files and Folders is STILL CHECKED, but our app can no longer access/open the file we desire. And the user is no longer prompted by the system to grant access. This is in an app that does NOT adopt sandboxing.
I'm going to try the obvious: explicitly present the location of our supporting document template to the user using NSOpenPanel, and see if that will restore access. Normally, the user doesn't ever directly select this file or its enclosing folder. But if that works, great.
Unfortunately, despite discussing this issue with DTS for 10 months, there's been no acknowledgment that there is any issue / defect in MacOS that could cause what I'm seeing. So it MIGHT be pilot error, but hard to see how.