could the same be said of iOS?
iOS does not allow any access to files outside of the file picker or the apps own folders
You can't trust macOS Privacy and Security settings
141–150 of 175 posts
Re: You can't trust macOS Privacy and Security settings
#142Earlier quoted context omitted.
Sure. But the proper api call to make is selecting a picture. Not access to the photo library. That is an api design flaw, and simply a bad / obsolete implementation by the app developer. The complaint of the OP is that he can still open a file which is in the downloads folder. But that’s not what the user is doing. There’s no reason to give folder access at all. (Except for file sorting apps etc). The only “reason”…
I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory. If you don't want it to access a folder, then don't open a folder in it. This behavior gets used all the time in things like opening a folder in your IDE so it can access the whole project. The OS does allow file pickers that can only pick files and not direc…
> I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory.
Firstly: If that user has explicitly disallowed access to a particular directory in a system-wide filesystem access control dialog, the intent to prevent access to that directory seems completely clear. In cases like this, it seems fine to me to have a "Grant read/write/list permissions to this directory? [Once] [Forever]" dialog that this access attempt causes to pop up.
Secondly: Directories with XY3 or XY1 permissions are not unheard of. If you want programs to be able to access a directory but not be able to list its contents, that's what you'd do. Perhaps you don't want people to be casually able to read the metadata on files in that directory. I have a vague, distant, and extremely unreliable memory that tells me that this was a technique used by some *nix mail or print spooling software way back when, but... "extremely unreliable memory".
This configuration would probably cause most GUI file pickers to shit their pants, but there's absolutely nothing that says that you need to have either 'r' or 'w' privs to a directory for a GUI file picker to actually function. Nearly every one of them that I've used contains a text box that you can use to punch in path components and filenames.
Re: You can't trust macOS Privacy and Security settings
#143The problem with Mac’s sandbox system is that it’s giving me some PTSD of Windows UAC. It’s inventing a solution to a problem that might exist in small doses, but instead gives users permission fatigue. I personally think the traditional *nix model has served us quite well, and elective sandboxing using containers (à la Docker and so on) is quite good. The Mac sandbox model is probably ok for most normal users, but f…
BTW - UAC is not a security boundary, so UAC-bypass is not the same as privilege escalation, and there is no bounty for it, etc, etc. It's a common misunderstanding, probably in no small part due to Microsoft's own lack of communication around it.
Re: You can't trust macOS Privacy and Security settings
#144Earlier quoted context omitted.
Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.
That URL should expire after a relatively short time.
“Should” meaning “I believe it currently does expire after a short time”?
Or “should” meaning “Apple should change this to expire after a short time”?
Re: You can't trust macOS Privacy and Security settings
#145Earlier quoted context omitted.
> It’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app. In the case of sandboxed apps, this is not true. The open panel provides temporary access, and a sandboxed app needs to create a security-scoped bookmark to retain persistent access across launches. For non-sandboxed apps, it's usually not an issue, because non-sandboxed apps hav…
The security-scoped bookmark is exactly why a user should treat all macOS file access permission prompts as permanent. There is also no UI to show to a user whether an app has created a security-scoped bookmark. And this is for sandboxed apps. You correctly point out that non-sandboxed apps have even more access. So a user’s mental model should be that all open dialogs grant permanent access.
tccutil reset All co.eclecticlight.Insent and reboot isn't actually working for me.
Thus, there's no way to remove access short of disabling SIP and deleting the com.apple.macl xattr.
Re: You can't trust macOS Privacy and Security settings
#146Earlier quoted context omitted.
That URL should expire after a relatively short time.
“Should” meaning “I believe it currently does expire after a short time”? Or “should” meaning “Apple should change this to expire after a short time”?
It doesn’t expire, you can even move the file and you can update the bookmark to follow the move.
There are legitimate reasons to give an app persistent access to a file or directory. Maybe you want it to write to a particular directory in your iCloud storage or whatever so it syncs without having to select the directory every time. A note taking app for example.
Re: You can't trust macOS Privacy and Security settings
#147Earlier quoted context omitted.
Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.
That URL should expire after a relatively short time.
No, it shouldn’t. There are real reasons to give persistent access to a particular directory. Maybe you want your note taking app to put all notes in a directory for iCloud/dropbox/google drive/some other sync service.
Re: You can't trust macOS Privacy and Security settings
#148That's the beauty of using a GUI-first operating system! > only way you can protect your Documents folder from access by Insent is to run the following command in Terminal: tccutil reset All co.eclecticlight.Insent then restart your Mac
Jobs is turning in his grave. There are lots of stories of this conflict at NeXT and Mac OS X where there's a quick fix but not via GUI, which was one of the many things that incensed him.
Then there's the OS/400 approach: Build TUIs that allow the user to set arguments and then just run command the line tools on submit. It was a really nice blend of two approaches and made things like man pages somewhat superflous.
Re: You can't trust macOS Privacy and Security settings
#149Earlier quoted context omitted.
Every time you relaunch the app?
It depends on the app whether that would make sense. If it is document centric, then yes. The user should explicitly open every time. If it doesn't make sense for the user to open it every time, it should ask for permanent permission and that should be recorded in system settings where it can be removed.
This seems like it would not work well with state restoration
Re: You can't trust macOS Privacy and Security settings
#150is this is why apple pushed an update yestersay?
No.