
Last Week on My Mac: Deceived by the Finder - miles
https://eclecticlight.co/2020/03/08/last-week-on-my-mac-deceived-by-the-finder/
======
sibartlett
Third-party apps are sandboxed on macOS. You have to explicitly grant them
access to the file system.

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.

~~~
tinus_hn
This is exactly the same thing as happens on Windows, the real permissions are
far too complex to convey in a simple dialog.

It’s just more sour grapes about SIP. Tough luck, it’s there to stay, if you
don’t like it, turn it off.

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

------
saagarjha
But Finder _isn’t_ lying here: it shows the ability to read or write the file,
but from Finder’s perspective. Just because you can do that doesn’t mean any
old app on your machine can by default. This is literally the manifestation of
Apple plugging holes in the UNIX permissions model. You can complain all you
want about “protected” directories being stupid, but arguing that Finder
should show you whether an arbitrary app can access a file is just inane.

~~~
owl57
Finder isn't some third-party tool released before this kernel change. Why
should it not know about those plugged holes?

~~~
saagarjha
How should it present this information?

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

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

~~~
dmitriid
From the user's point of view the file isn't accessible in any way except
through Finder.

If it _had_ read/write permissions as Finder shows it, all apps would be able
to, you know, read and write the file.

~~~
oefrha
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?

~~~
dmitriid
> 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?

Especially given how arbitrary these restrictions often are:
[https://news.ycombinator.com/item?id=22518229](https://news.ycombinator.com/item?id=22518229)

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

~~~
dmitriid
> As I said: when a dialog pops up.

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.

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

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

------
kirstenbirgit
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?

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

~~~
Wowfunhappy
Snow Leopard happened. High Sierra too, to a lesser extent.

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

~~~
zapzupnz
> 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).

Therefore, the outrage is manufactured.

------
listsfrin
This reminds me of the equivalent SELinux issues. Good ideas rushed out and
not packaged properly.

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

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

------
GiantSully
The battery of my 2018 MBP can not last even for 18 months before its
performance decreases drastically, which is disappointing.

~~~
zapzupnz
What does that have to do with anything?

