Comment by Wowfunhappy | Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

Parent Full thread

I'm not a fan of what Apple has done in Catalina, but I don't think your take is completely fair.

"For years", simply opening an app implicitly gave it access to most of the data on your hard drive. Regardless of whether you opened or dragged in a particular file.

In Catalina, Apple wanted to restrict this. As a consequence, in the initial release of Catalina, you could drag a file from your desktop into your Terminal, but your Terminal would be unable to access the file. Which of course is terrible UX!

So what Apple did in this update is give back the behavior you're describing: dragging a file into the Terminal implicitly grants the Terminal access. But unlike in old OS's, the Terminal doesn't suddenly get access to most of the other data on your hard drive as well.

Unfortunately, in order to walk that fine line, Apple had to add an extra, undocumented file attribute. And because Apple policy is for anything TCC-related should be SIP-protected, that attribute is protected by SIP and cannot be manually edited. And because a UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either...

Apple's intentions with all of this absolutely make sense. The problem is that good intentions don't matter if the execution is flawed.

> 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.

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…)

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.

> This is the kind of setting you'd want to control via either the Terminal (ironically) or a third party app:

I'm replying to my own post many hours later, because something just occurred to me:

There’s no reason the Terminal or a third party shouldn’t be able to remove this attribute. Just restrict adding the attribute!

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.

Why is everyone so fixated on Settings!

Put the access details in the Get Info of the files in Finder.

This is normal behavior. In DaisyDisk, you must drag the volume to the DaisyDisk window to grant it permission to inspect the volume. This is exactly the same behavior for Terminal.app. I don't see anything wrong here.

What's wrong is there's no way to revoke the permission if you dragged the file on accident. That is a HUGE flaw. Every app has an "undo" function for a reason.

I am talking about a very specific feature of the Powerbox that gives you a security scoped bookmark to access a resource, even if you are sandboxed: https://news.ycombinator.com/item?id=21828138

> And because a UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either...

Citation needed. It is just a list. I don't see the "nightmare".

Reply on news.ycombinator.com