Apple really needs to spend a whole release cycle just fixing existing bugs instead of making new features.
Even simple things are faltering, like when logging in, macOS stops registering keypresses in the middle of entering my password. Switching screens around when docking my MacBook Pro. Important features like Time Machine silently corrupting your files.
It's such a shame that macOS just keeps getting more buggy. I've read from multiple (ex) employees that there's no real incentive to fix bugs, since employees seem only to be rewarded when they're working on prestige projects.
What good is investing so much R&D into new hardware like Mac Pro when the operating system is the limiting factor?
Organizational inertia cannot allow this switch to fixing issues. That just don't happen at once because now a lot of people work in an environment rewarding them to only new feature development. This can be changed by replacing the whole tech organization motivation culture. Better at once.
I had so much frustration yesterday while renting a movie from Apple TV for my kids. I wanted to view it on my wife's laptop (also a Macbook), apparently she can't download the Apple TV app unless she subscribes. I had the app from when I had the TV trial. Overall such a poor and buggy user experience, not going into details, but I hear these devs are getting 400k/yr for not giving a shit about the overall user experience.
How about: not from Finder's point of view? There is no such thing as Finder's point of view. It must show info from the currently logged in user's point of view.
The entire point is that the user permissions are not accurate for an arbitrary app because of sandboxing. This is like yelling at readelf for "deceiving you" because the binary is slid around by layout randomization to somewhere else.
From the user’s point of view, the file is readable and writable by any app if full disk access is granted, and the user is able to grant full disk access if they so chooses (assuming an admin account here). So the file is indeed readable and writable from the user’s point of view. The presentation is accurate. You can argue about whether requiring full disk access is warranted, but you’re arguing the wrong thing.
This is just completely wrong, and I don’t want to explain Unix permissions vs actual access control again which has shown up more than once in the thread. Plus, you know what, sandboxed apps basically can’t read or write anything not created by them without explicit permissions.
The standard flow is app tries to access file/folder, dialog pops up asking if you want to allow access, or if you want to allow full disk access (the full disk access part might be opt in for app developers, but app developers with legit reasons to access certain protected stuff do tend to encourage users to do this).
Your apparent lack of knowledge of this (not pleasant but at least functioning) flow makes me wonder if you’re even a macOS user. Maybe just a Linux user who came to score some points?
> This is just completely wrong, and I don’t want to explain Unix permissions vs actual access control again which has shown up more than once in the thread.
If it wrong, then it's bot the job of HN threads to explain this to the user, but of the OS.
> Your apparent lack of knowledge of this (not pleasant but at least functioning) flow makes me wonder if you’re even a macOS user.
Ah. Ad hominem attacks, how nice.
I am a MacOS user. And I'm sick and tired of Catalina giving no human and humane ways of dealing with the mess it creates out of permissions.
Where do you expect a MacOS user to find out whether a random file is accessible to an app?
> Where do you expect a MacOS user to find out whether a random file is accessible to an app?
As I said: when a dialog pops up.
Btw, that’s not an ad hominem attack, it’s reasonable doubt about your experience with the subject matter given what you have expressed and left out so far. If you’re not even a user then it’s apparently pointless to explain further. Anyway, it’s still pointless to explain further when you know what you’re talking about yet still insist on conflating concepts, but stop pretending it was somehow personal.
So, I have to run every potential app on every potential file to see if the dialog pops up? You call that discoverability?
BTW as recently as a three weeks back I ran IntelliJ Rider on a folder that I created (not a system folder) and it started up in read-only mode. No dialogs, nothing.
Catalina randomly decided that a random application didn't have write permissions to user-created folder. Thank god I am a MacOS user, so I figured I should give the app access.
BTW. Is it "Developer Tools" access, "Full Access" or "Full disk access" and what is the difference?
> when you know what you’re talking about yet still insist on conflating concepts
I couldn't give two craps about "conflating concepts". It is the OS that conflates these concepts with poorly thought out permissions system with hardcoded filenames in its kernel, and gives me, the user, zero indication on whether something is accessible, readable, writeable or not. Except for a useless popup dialog which might or might not appear and gives zero indication on what specific permissions are lacking.
But yeah, "the user is at fault and the system behaves correctly". No, it doesn't.
> I couldn't give two craps about "conflating concepts".
Good for you. Next time maybe say it upfront when replying to a comment that has demonstrated a clear interest in not conflating the concepts and instead be annoyed about the thing that is actually annoying, not some tangent.
So. Once again: what is the way for a MacOS user to see a file's permissions and access?
Finder shows Unix permissions which obviously not enough.
Catalina itself may or may not show a dialog when accessing a random file from a random location by a random app (you never know which file or directory will suddenly be protected from access entirely or inaccessible to an app, and whether Catalina will show a warning when accessing it).
Somehow, your answer is: the user is the problem.
Nope. It's not the user who is for the computer. The computer is for the user. If the central place to display info on a file cannot show correct info on a file, that place has to be fixed.
There is limited application access to this file. You have the right to give permissions to applications to access the file - click here for more information.
Ivan Krstić has been trying to push this system for over a decade now. Maybe it just isn’t a good idea because over a decade of iteration and it still isn’t intuitive or exposed to the user in an understandable manner.
You can see this with Linux as well. For example, with ext# file systems, extended attributes allow you to make files append-only, copy-on-write, or give files project and version numbers. It also lets you decide which files are or are not compressed if the file system is set to be compressed. Other attributes determine what happens to a file when you delete it (nothing, zeroing the sectors, etc)
The chattr/lsattr commands are used for accessing them.
The only time I've seen these come up are for secure locations that set log files to append-only. But I'm sure there are people out there that swear by extended attributes.
> Third-party apps are sandboxed on macOS. You have to explicitly grant them access to the file system.
There’s missing nuance there. The “full disk access” and similar permissions apply even if an app is not using the traditional macOS Sandbox. Only software from the Mac App Store is required to use the traditional Sandbox, but the restrictions on disk access to certain directories apply to all processes not whitelisted (implicitly or explicitly), regardless of Sandboxing.
This nuance is somewhat important because an app listed “Sandbox: No” in e.g. Activity Monitor is still subject to disk access restrictions.
Finder is not really lying to you. It's just showing the truth from a standard viewpoint. The OS, however, creates another view from the application perspective - one which now imposes additional access rules.
I’m failing to understand the implied outrage here? Permissions have become far more nuanced than traditional UNIX, and can no longer be understood with only chmod literacy.
Apple doesn’t go out of its way to educate users about these changes because it’s supposed to be as transparent as, say, APFS’s file compression and encryption. HN has nothing but scorn usually for these “un-Professional” users that tend not to spend their time doing binary diffs on new point updates of MacOS housekeeping daemons. They do get a lot more actual work done, though.
The article doesn’t even try to make any specific point how these changes hurt anybody. Indeed the author mentions that nobody would have noticed if not for people running ‘strings’ on new binaries.
Millions of people have been running these changes, none of them even noticed, and all were presumably at least a bit safer than before. People at Apple must be feeling like tourists in bizzarroworld seeing people trying to scandalize this.
> I'm failing to understand the implied outrage here?
Because it's entirely manufactured. The writer doesn't seem willing to differentiate file permissions from a sandboxed application's permissions to access the file.
Once a sandboxed application is granted permission to access the file system, those file permissions still apply.
For non-sandboxed applications, those permissions still apply.
For non-GUI applications that run in the command line or as daemons, those permissions still apply.
Nothing is inaccurate. There is no lie. File permissions and applications' permissions to escape the sandbox are separate concerns with their own user interfaces (Finder and the Security & Privacy preference pane in System Preferences, respectively).
37 comments
[ 3.0 ms ] story [ 90.4 ms ] threadEven simple things are faltering, like when logging in, macOS stops registering keypresses in the middle of entering my password. Switching screens around when docking my MacBook Pro. Important features like Time Machine silently corrupting your files.
It's such a shame that macOS just keeps getting more buggy. I've read from multiple (ex) employees that there's no real incentive to fix bugs, since employees seem only to be rewarded when they're working on prestige projects.
What good is investing so much R&D into new hardware like Mac Pro when the operating system is the limiting factor?
I would pay proper old-school Mac OS release prices for this upgrade.
If it had read/write permissions as Finder shows it, all apps would be able to, you know, read and write the file.
The standard flow is app tries to access file/folder, dialog pops up asking if you want to allow access, or if you want to allow full disk access (the full disk access part might be opt in for app developers, but app developers with legit reasons to access certain protected stuff do tend to encourage users to do this).
Your apparent lack of knowledge of this (not pleasant but at least functioning) flow makes me wonder if you’re even a macOS user. Maybe just a Linux user who came to score some points?
If it wrong, then it's bot the job of HN threads to explain this to the user, but of the OS.
> Your apparent lack of knowledge of this (not pleasant but at least functioning) flow makes me wonder if you’re even a macOS user.
Ah. Ad hominem attacks, how nice.
I am a MacOS user. And I'm sick and tired of Catalina giving no human and humane ways of dealing with the mess it creates out of permissions.
Where do you expect a MacOS user to find out whether a random file is accessible to an app?
Especially given how arbitrary these restrictions often are: https://news.ycombinator.com/item?id=22518229
As I said: when a dialog pops up.
Btw, that’s not an ad hominem attack, it’s reasonable doubt about your experience with the subject matter given what you have expressed and left out so far. If you’re not even a user then it’s apparently pointless to explain further. Anyway, it’s still pointless to explain further when you know what you’re talking about yet still insist on conflating concepts, but stop pretending it was somehow personal.
So, I have to run every potential app on every potential file to see if the dialog pops up? You call that discoverability?
BTW as recently as a three weeks back I ran IntelliJ Rider on a folder that I created (not a system folder) and it started up in read-only mode. No dialogs, nothing.
Catalina randomly decided that a random application didn't have write permissions to user-created folder. Thank god I am a MacOS user, so I figured I should give the app access.
BTW. Is it "Developer Tools" access, "Full Access" or "Full disk access" and what is the difference?
> when you know what you’re talking about yet still insist on conflating concepts
I couldn't give two craps about "conflating concepts". It is the OS that conflates these concepts with poorly thought out permissions system with hardcoded filenames in its kernel, and gives me, the user, zero indication on whether something is accessible, readable, writeable or not. Except for a useless popup dialog which might or might not appear and gives zero indication on what specific permissions are lacking.
But yeah, "the user is at fault and the system behaves correctly". No, it doesn't.
Good for you. Next time maybe say it upfront when replying to a comment that has demonstrated a clear interest in not conflating the concepts and instead be annoyed about the thing that is actually annoying, not some tangent.
Finder shows Unix permissions which obviously not enough.
Catalina itself may or may not show a dialog when accessing a random file from a random location by a random app (you never know which file or directory will suddenly be protected from access entirely or inaccessible to an app, and whether Catalina will show a warning when accessing it).
Somehow, your answer is: the user is the problem.
Nope. It's not the user who is for the computer. The computer is for the user. If the central place to display info on a file cannot show correct info on a file, that place has to be fixed.
Sharing and Permissions
There is limited application access to this file. You have the right to give permissions to applications to access the file - click here for more information.
Finder is not lying at all. The permissions it shows in “Get Info” are the user/group permissions; not app permissions.
Maybe Apple could enhance the UX somehow to better what’s going on, but I wouldn’t go as far as to say Finder is lying.
It’s just more sour grapes about SIP. Tough luck, it’s there to stay, if you don’t like it, turn it off.
The chattr/lsattr commands are used for accessing them.
The only time I've seen these come up are for secure locations that set log files to append-only. But I'm sure there are people out there that swear by extended attributes.
There’s missing nuance there. The “full disk access” and similar permissions apply even if an app is not using the traditional macOS Sandbox. Only software from the Mac App Store is required to use the traditional Sandbox, but the restrictions on disk access to certain directories apply to all processes not whitelisted (implicitly or explicitly), regardless of Sandboxing.
This nuance is somewhat important because an app listed “Sandbox: No” in e.g. Activity Monitor is still subject to disk access restrictions.
Nit: not every App Store app must be sandboxed.
> 2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind: (i) They must be appropriately sandboxed
[1] https://developer.apple.com/app-store/review/guidelines/
I'm not.
Apple doesn’t go out of its way to educate users about these changes because it’s supposed to be as transparent as, say, APFS’s file compression and encryption. HN has nothing but scorn usually for these “un-Professional” users that tend not to spend their time doing binary diffs on new point updates of MacOS housekeeping daemons. They do get a lot more actual work done, though.
The article doesn’t even try to make any specific point how these changes hurt anybody. Indeed the author mentions that nobody would have noticed if not for people running ‘strings’ on new binaries.
Millions of people have been running these changes, none of them even noticed, and all were presumably at least a bit safer than before. People at Apple must be feeling like tourists in bizzarroworld seeing people trying to scandalize this.
Because it's entirely manufactured. The writer doesn't seem willing to differentiate file permissions from a sandboxed application's permissions to access the file.
Once a sandboxed application is granted permission to access the file system, those file permissions still apply.
For non-sandboxed applications, those permissions still apply.
For non-GUI applications that run in the command line or as daemons, those permissions still apply.
Nothing is inaccurate. There is no lie. File permissions and applications' permissions to escape the sandbox are separate concerns with their own user interfaces (Finder and the Security & Privacy preference pane in System Preferences, respectively).
Therefore, the outrage is manufactured.