
Undocumented Catalina file access change - chmaynard
https://lapcatsoftware.com/articles/macl.html
======
cannam
If I'm reading this correctly: as soon as you drag a path into the terminal
window, anything run from Terminal has access for that path apparently
permanently, through a special hidden capability attribute, bypassing the
usual Catalina permissions dialog.

Assuming it's true - I've no reason to think otherwise but I'm not using a Mac
at the mo so can't try it - this is fascinating. It has the ring of a quick
workaround for something: in desperation we bung in a whole new capability for
this, let's hope nobody notices, we'll do it properly in a later release. Is
there a better explanation? If it is a grubby workaround, what would it have
been a workaround for?

~~~
Wowfunhappy
It's a workaround for the new permissions system in Catalina being a complete
mess from the get go. Previously, the Terminal in Catalina would pop up a
dialogue asking for permission to access the file you'd just dragged in.

Good security or not, this entire system should not have been rolled out
unless/until Apple had a sane UI for handing it. They don't.

~~~
heydabop
> It's a workaround for the new permissions system in Catalina being a
> complete mess from the get go.

I fucking hate it. Programs can write to my user dir and folders within it
freely, but god forbid they touch my sacred Downloads, Documents, and Desktop
folders! Better ask me first!

It's like it was made by the iOS dev team but also the iOS dev team has
_never_ used a computer before.

I had to add ruby to full disk access to get emacs to work, because emacs is
launched by a ruby script and it was insane that I couldn't ls my Downloads
folder from it.

~~~
geofft
Given how absolutely terrible "real" computers are at having a meaningful
security model (see also [https://xkcd.com/1200/](https://xkcd.com/1200/)), I
am entirely in favor of letting the iOS dev team, who have implemented a
meaningful security model, design things while making sure they never hear
about how "real" computers work.

~~~
realusername
The problem with that is iOS is only a consumption device, not an actual
computer, their security model makes no sense if you are using the device like
a computer.

~~~
geofft
I use my iPhone like a computer. (I think. I mean, I don't spend a bunch of
time cleaning up malware on it or reinstalling my Python environment because
something got screwed up one day, does that mean I don't use it like a
computer?)

~~~
realusername
You can but it's not really designed for that usage, hard to access files,
unability to create a folder hierarchy, a lot of use-cases are outright
forbidden by Apple...

------
crazygringo
The motivation seems laudable: obviously if I drag a file to the terminal I
want it to be able to access it, one less confirmation dialog the better.

But it's the implementation that seems deeply flawed: that there's no obvious
way to remove the permission afterwards, or even a record of it where you'd
expect to look.

There seems to be a reasonable solution, however: as soon as the terminal
window gets closed (and perhaps any background processes ended), the
permissions get revoked. And even if your terminal process gets killed without
cleanup, permissions would be revoked when your terminal app reboots or your
computer restarts.

That could work, right?

~~~
pmarreck
The problem is that whoever implemented this change did not care to consider
the full workflow lifecycle/consequences of enabling that change. And whoever
did the code review on it ALSO failed to consider, or push for, dealing with
it holistically and thoughtfully instead of just GSD’ing it (“gettin’ shit
done”)

This is not the Apple I grew up with.

~~~
floatingatoll
What if they did fully consider it, and reached a decision that you disagree
with?

~~~
jerf
I have a hard time buying that anyone deliberately shipped a security feature
that permanently opens access short of rebooting the system into a special
mode. A "full deliberation" would presumably include input from a dedicated
security team, who would almost certainly say "better not to ship this at all
and leave the old behavior in than ship this". So either the security team
missed this entirely, or the security team was not consulted, or the security
team is not empowered to stop this sort of half-baked feature from going in...
I really can't come up with a pleasant scenario here.

~~~
jjoonathan
"We're trying to ship a system-wide permission lockdown, but we ran into
unforeseen complications that will require more than a single release cycle to
properly address. Instead of holding up the entire rollout for a release
cycle, we'll ship the lockdown today and most users will benefit from it, but
users that would otherwise run into the complications get a permissive bypass.
Once the infrastructure to address the complications is in place, we'll get
the lockdown working for them as well."

~~~
jerf
The near-complete inability to revert the permission is what argues against
this. You could get this past a security team if you had the ability to revert
it and Apple could document it away. It is the fact that it is a _non-
revertible_ thing (in any reasonable manner) that is the key here. The odds
that there's some way to chain this in an interesting way are just too high,
even if the security team couldn't immediately come up with it.

------
Wowfunhappy
Thank god.

Yes, logically, if I drag a file into the Terminal, I want Terminal to be able
to access that file.

Should be documented somewhere, probably, but very clearly a positive change.

~~~
spsful
By the same logic, typing out the filename should make the same permissions
change, no?

~~~
saagarjha
No. The action of pasting or dropping the file is what gives access.

~~~
spsful
I wasn't saying that to suggest a practical use of this "bug", just to point
out that if it were as intentional as the above commend suggested then it
should have been expanded to other methods of listing the file directory like
typing it in.

------
abtinf
It used to be you could trust your software—even most closed source—because
only bad guys wanted to exfiltrate data from your system. The simple advice of
“never run an unknown executable” was an effective security practice.

Now, the incentives of software vendors—even open source—have changed to
include data exhilaration en masse. Off the top of my head:

* Games that scan and upload the file hierarchy of your system.

* Software sync packages that casually provide third parties for research (Dropbox).

* Keyloggers embedded in the default operating system (web search in windows start; Ubuntu web search; Siri web search.

* Pervasive practice of running untrusted code with JavaScript and the seemingly inexorable march of granting web pages greater system access. Copy something to your clipboard, open a web page, and it can grab it, along with so much more.

* The push toward ever greater “telemetry”.

* Automatic background file uploads, like Microsoft defender sample submission.

* Pervasive ingestion of our data by governments.

The greatest threat to our security has become the vendors and government—the
very entities whose job it is to protect us.

~~~
saagarjha
> Keyloggers embedded in the default operating system (web search in windows
> start; Ubuntu web search; Siri web search.

How exactly are these keyloggers?

~~~
tenebrisalietum
They send each keypress in a search to a remote service who is able to log it.

~~~
saagarjha
I mean, how else do you expect web searches to work?

~~~
mr__y
I would expect them to send search the query if and when I search for
something and send exactly nothing when I don't

~~~
saagarjha
Aren't you literally searching for something in this case?

~~~
mcbits
Yes, searching for a local file or program 100% of the time because I would
never intentionally search for anything else from there.

That's specifically for Windows Start. If Ubuntu or Siri "web searches" are
clearly distinguished from OS searches, then of course I'd expect them to send
data somewhere.

~~~
lrem
Wait, how do you know that does search per keypress? I've just tried in
Windows, and it doesn't seem to do anything until I press enter when the loupe
is selected.

------
fiddlerwoaroof
I don’t know what use a terminal application is without full disk access: the
first two things I do on a new Mac are disable SIP (so I can use dtrace
effectively) and grant all my terminal applications full disk access. I’m
getting really tired of Apple’s “security” policies that have no user-
controllable ways to override the defaults.

~~~
mindfulhack
What it has made me actually very grateful for is the sudden revelation - to
me - that Dropbox, Google Drive and others are secretly reading files that I
never explicitly asked - or wanted - them to read. macOS now asks and allows
me to block by default.

No, Google, I DIDN'T intend for you to snoop in my Mac ~/Downloads folder -
that area is PRIVATE. So in a way it's good for user Privacy, Apple
Inc.-aside.

~~~
BuildTheRobots
Hang on, Google and Dropbox are snooping around on the filesystem outside of
their configuration or explicitly shared folders?

~~~
mindfulhack
Yes. I was shocked at it, but on second thought I'm not surprised. Since
Catalina, security prompts come up early on about Dropbox and Google Drive
wanting to access your "Downloads" folder. Caught red-handed.

I know there's been third-party macOS apps providing this 'filesystem
firewall' functionality for years now, but it's nice to have some of it come
from Apple directly.

I think I will eventually move to Linux, I just don't feel private on my own
damn computer anymore. I don't trust Apple either. Or I will harden macOS more
and more because of this abuse.

------
overgard
Remember when Windows Vista first came out, and people reviled the utterly
useless intrusive UAC security dialogues that would pop up every 10 seconds?
And the inexplicable confusing security model that just broke most things? And
the fact that it was a waste of time because it just trained people to hit
"yes" all the time?

Apparently Apple doesn't remember, because they seem intent to make all the
exact same mistakes.

~~~
ken
Is this alert appearing multiple times for every app on the system, or just
for Terminal and only once ever?

Since I'm only hearing about this in a techie article about Terminal, I think
it sounds completely different from Vista UAC.

~~~
saagarjha
It's once per app that tries to access something restricted.

------
samwillis
Personally I’m all for increased protection in an OS, the old model of users
having permissions no longer works. You can’t trust your users, they don’t
know what they are running when they install software. This new model of each
“app” having permissions is far more sensible, more of that please!

~~~
vbezhenar
I'm one of the users and I don't need protections, I need freedom.

~~~
tpmoney
Do you run as root on all your systems?

~~~
vbezhenar
I run as root when I need it.

------
a1k0n
after updating to Catalina I was suddenly unable to edit my own ~/.ssh/config.
I still can't figure out why not. I could rename it and make a copy, though,
and the old one shows this:

-rw-r--r--@ 1 aaaaaaa staff 2571 Sep 15 2017 config~

com.apple.finder.copy.source.checksum#N 4

com.apple.metadata:_kTimeMachineNewestSnapshot 50

com.apple.metadata:_kTimeMachineOldestSnapshot 50

that file remains read-only to me. what is going on?

~~~
coldtea
It doesn't say "config" above, it says "config~".

Isn't that like a Vim backup file? Or that's the copy you renamed?

~~~
ashton314
I think that's an emacs backup file. Does Vim also use the <filename>~ format
too?

------
c-smile
Another trap with this that I found myself in.

I had an XCode project sitting in folder on desktop. Small utility that I
modify frequently.

After Catalina upgrade compilation of that project stopped working.

XCode started complaining "file is inaccessible" or something like that.
Peculiarity is that you can open that file from IDE through Open containing
folder / Finder.

And XCode provides absolutely no clue why it cannot access files of the
project...

Road that is seeded by such good intentions goes where?

~~~
skunkworker
Try running xattr on the file in the terminal. It might include why it can’t
open it

~~~
c-smile
Yeah but that would be the last option you will think of when you will try to
re-compile project that was working just yesterday ...

~~~
skunkworker
I learned about this option last week after a app I installed wouldn't open,
but from a different zip it would while they both had the same MD5 and SHA
hash. There was a xattr flag on it that prevented it from working. Just a
hunch.

------
jtaft
Not related, but my "/backup" folder was removed by Catalina upon upgrading.
Of course I backed up "/backup" to an external drive daily, but still...not
cool.

~~~
saagarjha
It should have been moved to a "Relocated Items" or "Previous System" folder,
or something similar.

~~~
jtaft
Interesting, thanks! They moved to /Users/Shared/Relocated Items .

------
ridaj
"Millennials are killing Unix" — well put — in what world does a _system
shell_ application need permissions to access files?! It's _supposed_ to let
you poke under the hood, shouldn't it have that permission to begin with?

Plus, if drag-and-drop somehow enables Terminal to get that file permission,
then I guess either of two things: (a) Terminal is special -cased to be the
only such app capable of gaining that kind of permission from a drag-and-drop,
in which case well why didn't they just grant it permission from the start; or
(b) it can be exploited by any other app to gain similar permissions on drag-
and-drop of a file onto the app... ?

------
saagarjha
I don't think this is new? Applications usually get automatic access to files
you drag or copy into them; this is a Powerbox feature that has been around
for a while. This presumably just extends the feature to the new restricted
directories, using a new xattr instead of the one used previously
(com.apple.security.private.scoped-bookmark-key, I think?).

------
computerex
Okay this is very strange. It seems like OSX is regressing in the file
permissions experience and heading towards a more Windows like experience.
Considering how incredibly annoying the Windows file permissions experience
can be, I think that's a terrible direction to head towards. There are so many
complaints of people being unable to access files after the Catalina upgrade.
I hope they simplify their permissions and adopt a more sane/less user hostile
model. Security needs to be implemented in such a way that it doesn't get in
between using my device for work.

------
chadlavi
> because Millennials are killing Unix

How is this our fault?

~~~
notatoad
Everything is our fault. Haven't you been paying attention?

~~~
e40
According to my millennial son, boomers screwed up everything.

~~~
Ididntdothis
Exactly!

~~~
OrangeMango
The boomers knew you'd blame them, so they preemptively blamed the silent
generation.

[https://www.youtube.com/watch?v=eFTLKWw542g](https://www.youtube.com/watch?v=eFTLKWw542g)

------
tinus_hn
> because Millennials are killing Unix.

This is where I closed the article.

------
Quiark
I can't get these disk restrictions to work.

1) I granted full disk access to iTerm2. Later I removed them in the UI and I
can still do everything in iTerm. 2) I have "Documents" granted to a Java app.
Tried opening or saving a file in various locations and didn't notice any
restriction other than my ordinary UNIX user's 3) I created an app bundle
containing a plain shell script that reads my firefox cookie file and curls
the file somewhere. This app runs just fine with no prompt whatsoever.

Am I being stupid here or what's up?

------
professorTuring
I'm reading comments and I think some of them are unfair.

First of all, I can see how this functionality is oriented towards the average
Joe, not developers, sysadmins or hackers in general.

This helps the user, to an extent, to protect his assets from malware or
accidents.

Also, it is undocumented, probably for a reason, this could be an early
version that will be evolved and announced once the feel comfortable.

------
alanh
Tangentially, for pages like this that don’t have any sort of max-width set,
you may want to use a bookmarklet like "Force Narrow Page" available here
[https://alanhogan.com/bookmarklets](https://alanhogan.com/bookmarklets) — or
of course one of the reading-mode browser extensions, etc

------
akerro
Ok, so this isn't about Tomcat...

------
Ericson2314
See Apple does a bunch of breaking changes "for security", and we don't know
whether to thank them or curse them, but then stuff like clears it up.

They are unsystematicaly doing whatever the hell they like, without regard to
consistency or compatibility.

------
brown9-2
Something sounds weird about a terminal app (running as me) running a shell
(running as me) not being able to access a directory owned by me.

~~~
saagarjha
This is the entire goal behind sandboxing.

------
EGreg
Don’t you mean illegal Catalina file access change?

Did you just change the permissions on that file? That’s against the rules
isn’t it?

------
jrochkind1
I wish I could just stick with my 2015 Macbook Pro (USB-A and no touchbar) and
MacOS 10.12 forever.

I feel like that was the pinnacle of Apple hardware/software.

~~~
Wowfunhappy
Why Sierra over High Sierra? To me, that's like saying Leopard is the pinnacle
when Snow Leopard exists.

(I have very strong feelings about individual OS X versions)

~~~
spsful
Can't forget the migration to APFS. For me that was reason alone to upgrade
from Sierra.

------
jiveturkey
> It's well known

I didn't know that! Lovely feature.

~~~
kccqzy
I remember reading if you drag an NSAttributedString with
background/foreground color, that will change your terminal colors too.

------
vorpalhex
It really feels like Apple's OS updates have started to become user hostile in
an attempt to "iOS-ify" MacOS.

~~~
donarb
How is this user hostile? The behavior described is that the Terminal is
granted access to the file automatically when the user specifically tries to
access the file in Terminal.

~~~
thawaway1837
Because you cannot revoke that access either through GUI tools, or through
sudoed terminal commands.

I think this is most likely a bug, but if not, then it is definitely user
hostile.

~~~
saagarjha
I doubt this is a bug; a similar feature has been available in the app sandbox
for a while.

