> And because the UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either.
Why would this be a complete nightmare? There's no way to override a permission that's been granted to your ancestor - so why shouldn't the OS be able to remove the flag when you remove the permission in Settings? Why shouldn't the OS be able to maintain the invariant between the permissions dialog and the on-disk representation, given that the on-disk representation can only be set by the OS? That's just sad.
The OS can certainly remove the flag. I just can't imagine what the UI for that would look like in Settings, once you've dragged many hundreds of files into the Terminal over the course of using your computer for several months.
You could put it in the individual file's get info pane, but more users open that pane than know what the Terminal is.
This is the kind of setting you'd want to control via either the Terminal (ironically) or a third party app. But Apple has decided only Apple-supplied software with a UI is allowed to control TCC.
MacOS has some very strange ideas on removing permissions. When you allow kexts in modern OS releases, the signature gets added to an SQLite database in /var/db (you have to consult this database to get the signatures if you want to whitelist kexts in an MDM). Now kexts are quite invasive, hence Apple's caution on allowing them in the first place.
What happens if you want to revoke a kext? Delete the entry from the SQLite DB? Nah. Guess what, SIP prevents any and all deletions from that DB. You have to disable SIP to revoke a kext's permissions. And because the signature is not a hash, but instead a two-part vendor/product, it's entirely possible for a malicious version of an existing kext to be released that is then permitted by the signature.
As an admin with security focus, this to me seems completely backwards. I get that Apple don't want to make the permitting operation to be too difficult in the first place, because these are end-users we're talking about, but the lengths they go to in order to prevent the permissions being revoked is downright strange.
This is pretty straightforward in a locked-down Settings UI. Checkboxes that add to staging for a bulk "remove" action, a "select all visible" meta-checkbox, a search box to filter the view. Showing full paths might be tough, but you can wrap lines or ellipsize/tooltip if necessary, and rely on search for power users with deep hierarchies. Gmail has had this exact pattern for eons.
Right, because only Apple-supplied software can possess the right entitlements. If there was any other way to do this, applications could bypass the protection (looking at you, Dropbox…)
Why would this be a complete nightmare? There's no way to override a permission that's been granted to your ancestor - so why shouldn't the OS be able to remove the flag when you remove the permission in Settings? Why shouldn't the OS be able to maintain the invariant between the permissions dialog and the on-disk representation, given that the on-disk representation can only be set by the OS? That's just sad.