16 ms·

Undocumented Catalina file access change

566 points by chmaynard 7y ago

vorpalhex 7y ago
It really feels like Apple's OS updates have started to become user hostile in an attempt to "iOS-ify" MacOS.
- donarb 7y ago
  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.
  - vorpalhex 7y ago
    Through a super flag that can't ever be revoked even by sudo?
    - Wowfunhappy 7y ago
      The purpose of System Integrity Protection is to create a privilege level that not even superuser has access to. Luckily, if you’re an experienced user you can boot into recovery mode and permanently disable it, so it will never bother you again. Takes five minutes. Then sudo will be able to do anything. You can also selectively disable parts of SIP.
      - thawaway1837 7y ago
        But this behavior makes no sense at all. An accidental copy/paste means you cannot return the permissions to their default state without disabling SIP. Presumably the default permission is a good one, otherwise, if it’s so terrible that it’s a good idea to make it so difficult to go back to it, then why is it the default?
        jackhack 7y ago
        exactly. It's user hostile to correct/undo the action. A 2 second drag-drop mistake requires the following to correct it: 1. realize mistake / stop-everything-you're-doing 2. reboot to recovery mode 3. change SIP setting --> disabled 4. reboot to normal OS 5. delete attribute you never wanted 6. reboot to Recovery again 7. re-enable SIP 8. reboot to normal OS and get back to work if you can remember what you were even doing 20 minutes ago. That's "user hostile" in my book.
        ridiculous_fish 7y ago
        Why would you bother to do any of that? If you accidentally allow an unsandboxed app to access ~/Downloads without prompting, it's just like using a Windows or Linux or Mojave system. Who cares?
      - overgard 7y ago
        Creating a privilege level the user of the computer doesn't have access to sounds user-hostile to me. I'm all for security, but it's my computer. (I know you can reboot/turn it off etc., but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file because I dragged a file. What if I was dragging it somewhere else and my hand slipped off the trackpad?).
        Wowfunhappy 7y ago
        > but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file To be clear: you need to reboot your computer once, and from then on, sudo will always have full permission to do anything. You won't ever have to boot into recovery mode again unless you buy a new computer. You don't have to like the default, but when it's so darn easy to make your system work the way you'd like, I find it really hard to complain. Some guides will recommend making SIP-protected changes from within recovery mode as an alternative to disabling SIP permanently. But you absolutely don't have to do that.
        overgard 7y ago
        I know I can turn it off, but that's not the point. The point is that, if the standard advice for when it does something completely surprising and weird is "just turn it off", then it's a bad security feature. Granted I'm biased, because my experience with SIP has entirely been that it just breaks things and makes it impossible to fix it. Here's an example of an awful thing it did: if you happen to be using the builtin system python in an older version of macOS, and then you upgrade macOS, certain modules become unusable because the .pyc files they generated on older versions become completely locked by SIP, and the only way to fix it? Yeah, you guessed it, restart it and disable it. You might say, well, don't use the system python. Sure, but python installation is a mess on macOS anyway, and it wasn't my machine this was causing issues with, it was everyone else in the department. I just had to fix it. Also, it's frustrating as hell because essentially I'm disabling it to prevent macOS from screwing with itself. Which is entirely antithetical to the purpose of the feature in the first place (protecting os files). If the solution is always "turn it off", that's what people are going to do, and the entire feature becomes a frustrating waste of time. Also, I would argue there's nothing "easy" about having to reboot into a recovery mode to do this. It may not be hard, but it's a pain in the ass and totally pointless.
  - thawaway1837 7y ago
    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 7y ago
      I doubt this is a bug; a similar feature has been available in the app sandbox for a while.
    - deleted 7y ago
      [deleted]
    - lolsal 7y ago
      I don't think this behavior is user hostile.
- jandrese 7y ago
  This isn't really user hostile. The opposite really, stuff just works. It's possibly security hostile though, and admin hostile, especially since these out of band permissions are apparently very difficult to revoke. As an admin nothing gives me heartburn more than when the system does some sort of magic to make something just work, because I know whatever that process is will be poorly documented and difficult to manage.
  - jdjdjjsjs 7y ago
    It still doesn't make sense. If this is the better approach, then why isn't it the default. Why is it enabled (in a way that is extremely difficult to reverse) by copy pasting something in the Terminal? I'm pretty sure this is a bug that will likely be resolved in a couple of minor updates. Edit: Also, this is extremely user hostile. And it is security hostile. The user and securoty hostile bit isn't giving access when the user pastes a location in the terminal. The hostile bit is completely ignoring the users action when they subsequently try to disable access through the File Access dialog. And it's security hostile because the OS is making it difficult to remove access, not enable access.
    - jandrese 7y ago
      It's hard to imagine how this could be accidental behavior. It is much too specific. The only way I could see it being a bug (or incomplete feature) is if maybe there's supposed to be a prompt asking if you want to grant permission first that isn't working. And maybe some sort of permission manager that lets you add/revoke said permissions without a laborious reboot into a diagnostic tool.
      - jasonlotito 7y ago
        > It's hard to imagine how this could be accidental behavior. Ooops, I meant to drag it onto my desktop, but I accidentally dropped it onto my terminal. It's very easy to imagine how this could be accidental behavior.
        7y ago
Wowfunhappy 7y ago
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.
- mlyle 7y ago
  It's good except--- it being permanent and you can't take the right away is a bit surprising.
  - SamuelAdams 7y ago
    But that's a result of the Agile way of development. The MVP is "be able to drag a program to the terminal and run it", and the next feature, way down on the backlog is "allow the user to revoke permissions granted by dragged-in apps"
    - ryanianian 7y ago
      It's actually the result of product-owners deciding to release unfinished software, likely responding to incentives from management to ship (boolean) without clear standards about what is shippable (non-boolean).
      - saagarjha 7y ago
        I think you're trying to derive too much insight from a small change like this.
        Wowfunhappy 7y ago
        I agree, but it's not an unfair comment in light of what a mess Catalina and iOS 13 have been as a whole.
      - neuronic 7y ago
        Software always is and always will be unfinished.
deleted 7y ago
[deleted]
chadlavi 7y ago
> because Millennials are killing Unix How is this our fault?
- notatoad 7y ago
  Everything is our fault. Haven't you been paying attention?
  - chadlavi 7y ago
    I've been too busy eating avocado toast and taking out more student loans
    - deleted 7y ago
      [deleted]
    - reaperducer 7y ago
      "I eat Tide Pods and I vote."
  - e40 7y ago
    According to my millennial son, boomers screwed up everything.
    - Ididntdothis 7y ago
      Exactly!
      - OrangeMango 7y ago
        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
    - entelechy0 7y ago
      Ok boomer
deleted 7y ago
[deleted]
samwillis 7y ago
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!
- deleted 7y ago
  [deleted]
- Ididntdothis 7y ago
  Can you trust users to understand what the permission prompts really mean? Its like UAC in Windows where most people just press “yes” all the time.
  - klodolph 7y ago
    Exactly. This is why when you double-click on an arbitrary app you downloaded on macOS, there is no “yes” button. You have to bypass the protection by right-clicking on the app or by changing system settings. This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. I think this is the right choice!
    - strbean 7y ago
      I dislike the whole "Pop out the system settings dialog and enable things for the application" approach. It throws users into what is likely unfamiliar territory, which just obfuscates things further. I think a list of permissions with detailed explanations as to what they mean, and a Yes button, is a better approach. Although there needs to be an option to disable or even mock certain permissions.
      - Ididntdothis 7y ago
        Agreed. Especially since there is no explanation why the permission is needed and what it does in detail. I am a very experienced Windows dev but on my MacBook I have no idea what the exact implications are when an app requires access to “accessibility”. I am pretty sure the regular user doesn’t even have the foggiest idea but just does what he is told to do to make the app work. There is also no log what tells how the app uses the permission. It would be nice if there was a log of each use of the granted permission.
a1k0n 7y ago
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?
- geoelectric 7y ago
  Dumb question, of course, but you're logged in as aaaaaaa, right? That's what whoami returns?
  - a1k0n 7y ago
    yes yes, it is owned by me. i edited my username in the "screenshot".
- coldtea 7y ago
  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 7y ago
    I think that's an emacs backup file. Does Vim also use the <filename>~ format too?
  - a1k0n 7y ago
    i mv'd config to config~, then made a copy of it as config. the old file, now renamed to config~, is still read-only.
jiveturkey 7y ago
> It's well known I didn't know that! Lovely feature.
- kccqzy 7y ago
  I remember reading if you drag an NSAttributedString with background/foreground color, that will change your terminal colors too.
abtinf 7y ago
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 7y ago
  > Keyloggers embedded in the default operating system (web search in windows start; Ubuntu web search; Siri web search. How exactly are these keyloggers?
  - tenebrisalietum 7y ago
    They send each keypress in a search to a remote service who is able to log it.
    - saagarjha 7y ago
      I mean, how else do you expect web searches to work?
      - mr__y 7y ago
        I would expect them to send search the query if and when I search for something and send exactly nothing when I don't
cannam 7y ago
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 7y ago
  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.
  - saagarjha 7y ago
    The "sane UI" in this case is one that has already existed for years, and it's the user intent of dropping a file into an application to give it access.
    - djsumdog 7y ago
      I dunno. It makes me think of the Zen of Python's "Explicit is better than implicit." .. which is the point of the entire new Vista-style permission granting dialogues to begin with.
      - zerkten 7y ago
        Those dialogs recognized the product had to change significantly for the time and were accompanied by many changes below the surface. I'm not sure that the same level of recognition exists in Apple circles.
saagarjha 7y ago
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?).
jrochkind1 7y ago
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 7y ago
  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 7y ago
    Can't forget the migration to APFS. For me that was reason alone to upgrade from Sierra.
  - jrochkind1 7y ago
    okay, sure. :)
crazygringo 7y ago
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 7y ago
  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.
  - saagarjha 7y ago
    > The problem is that whoever implemented this change did not care to consider the full workflow lifecycle/consequences of enabling that change. Why do you think this is the case?
  - floatingatoll 7y ago
    What if they did fully consider it, and reached a decision that you disagree with?
    - jerf 7y ago
      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.
sproketboy 7y ago
Reasons not to upgrade yet.
akerro 7y ago
Ok, so this isn't about Tomcat...
jtaft 7y ago
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 7y ago
  It should have been moved to a "Relocated Items" or "Previous System" folder, or something similar.
  - jtaft 7y ago
    Interesting, thanks! They moved to /Users/Shared/Relocated Items .
  - hanche 7y ago
    Indeed, on my mac I found such an item in the Desktop folder after upgrading.
c-smile 7y ago
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 7y ago
  Try running xattr on the file in the terminal. It might include why it can’t open it
  - c-smile 7y ago
    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 7y ago
      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.
- deleted 7y ago
  [deleted]
genimelineji 7y ago
AAAh
deleted 7y ago
[deleted]
fiddlerwoaroof 7y ago
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 7y ago
  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 7y ago
    Hang on, Google and Dropbox are snooping around on the filesystem outside of their configuration or explicitly shared folders?
    - mindfulhack 7y ago
      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.
    - arh68 7y ago
      Yes maybe, at times, even Chrome: https://news.ycombinator.com/item?id=19653881 https://news.ycombinator.com/item?id=19653881
  - 7y ago
deleted 7y ago
[deleted]
brown9-2 7y ago
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 7y ago
  This is the entire goal behind sandboxing.
overgard 7y ago
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 7y ago
  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 7y ago
    It's once per app that tries to access something restricted.
alanh 7y ago
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
EGreg 7y ago
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?
Quiark 7y ago
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?
ridaj 7y ago
"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... ?
Ericson2314 7y ago
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.
professorTuring 7y ago
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.
computerex 7y ago
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.
tinus_hn 7y ago
> because Millennials are killing Unix. This is where I closed the article.

566 points by chmaynard 7y ago

vorpalhex 7y ago

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

donarb 7y ago
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.
- vorpalhex 7y ago
  Through a super flag that can't ever be revoked even by sudo?
  - Wowfunhappy 7y ago
    The purpose of System Integrity Protection is to create a privilege level that not even superuser has access to. Luckily, if you’re an experienced user you can boot into recovery mode and permanently disable it, so it will never bother you again. Takes five minutes. Then sudo will be able to do anything. You can also selectively disable parts of SIP.
    - thawaway1837 7y ago
      But this behavior makes no sense at all. An accidental copy/paste means you cannot return the permissions to their default state without disabling SIP. Presumably the default permission is a good one, otherwise, if it’s so terrible that it’s a good idea to make it so difficult to go back to it, then why is it the default?
      - jackhack 7y ago
        exactly. It's user hostile to correct/undo the action. A 2 second drag-drop mistake requires the following to correct it: 1. realize mistake / stop-everything-you're-doing 2. reboot to recovery mode 3. change SIP setting --> disabled 4. reboot to normal OS 5. delete attribute you never wanted 6. reboot to Recovery again 7. re-enable SIP 8. reboot to normal OS and get back to work if you can remember what you were even doing 20 minutes ago. That's "user hostile" in my book.
        ridiculous_fish 7y ago
        Why would you bother to do any of that? If you accidentally allow an unsandboxed app to access ~/Downloads without prompting, it's just like using a Windows or Linux or Mojave system. Who cares?
    - overgard 7y ago
      Creating a privilege level the user of the computer doesn't have access to sounds user-hostile to me. I'm all for security, but it's my computer. (I know you can reboot/turn it off etc., but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file because I dragged a file. What if I was dragging it somewhere else and my hand slipped off the trackpad?).
      - Wowfunhappy 7y ago
        > but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file To be clear: you need to reboot your computer once, and from then on, sudo will always have full permission to do anything. You won't ever have to boot into recovery mode again unless you buy a new computer. You don't have to like the default, but when it's so darn easy to make your system work the way you'd like, I find it really hard to complain. Some guides will recommend making SIP-protected changes from within recovery mode as an alternative to disabling SIP permanently. But you absolutely don't have to do that.
        overgard 7y ago
        I know I can turn it off, but that's not the point. The point is that, if the standard advice for when it does something completely surprising and weird is "just turn it off", then it's a bad security feature. Granted I'm biased, because my experience with SIP has entirely been that it just breaks things and makes it impossible to fix it. Here's an example of an awful thing it did: if you happen to be using the builtin system python in an older version of macOS, and then you upgrade macOS, certain modules become unusable because the .pyc files they generated on older versions become completely locked by SIP, and the only way to fix it? Yeah, you guessed it, restart it and disable it. You might say, well, don't use the system python. Sure, but python installation is a mess on macOS anyway, and it wasn't my machine this was causing issues with, it was everyone else in the department. I just had to fix it. Also, it's frustrating as hell because essentially I'm disabling it to prevent macOS from screwing with itself. Which is entirely antithetical to the purpose of the feature in the first place (protecting os files). If the solution is always "turn it off", that's what people are going to do, and the entire feature becomes a frustrating waste of time. Also, I would argue there's nothing "easy" about having to reboot into a recovery mode to do this. It may not be hard, but it's a pain in the ass and totally pointless.
- thawaway1837 7y ago
  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 7y ago
    I doubt this is a bug; a similar feature has been available in the app sandbox for a while.
  - deleted 7y ago
    [deleted]
  - lolsal 7y ago
    I don't think this behavior is user hostile.
jandrese 7y ago
This isn't really user hostile. The opposite really, stuff just works. It's possibly security hostile though, and admin hostile, especially since these out of band permissions are apparently very difficult to revoke. As an admin nothing gives me heartburn more than when the system does some sort of magic to make something just work, because I know whatever that process is will be poorly documented and difficult to manage.
- jdjdjjsjs 7y ago
  It still doesn't make sense. If this is the better approach, then why isn't it the default. Why is it enabled (in a way that is extremely difficult to reverse) by copy pasting something in the Terminal? I'm pretty sure this is a bug that will likely be resolved in a couple of minor updates. Edit: Also, this is extremely user hostile. And it is security hostile. The user and securoty hostile bit isn't giving access when the user pastes a location in the terminal. The hostile bit is completely ignoring the users action when they subsequently try to disable access through the File Access dialog. And it's security hostile because the OS is making it difficult to remove access, not enable access.
  - jandrese 7y ago
    It's hard to imagine how this could be accidental behavior. It is much too specific. The only way I could see it being a bug (or incomplete feature) is if maybe there's supposed to be a prompt asking if you want to grant permission first that isn't working. And maybe some sort of permission manager that lets you add/revoke said permissions without a laborious reboot into a diagnostic tool.
    - jasonlotito 7y ago
      > It's hard to imagine how this could be accidental behavior. Ooops, I meant to drag it onto my desktop, but I accidentally dropped it onto my terminal. It's very easy to imagine how this could be accidental behavior.
      - 7y ago

Wowfunhappy 7y ago

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.

mlyle 7y ago
It's good except--- it being permanent and you can't take the right away is a bit surprising.
- SamuelAdams 7y ago
  But that's a result of the Agile way of development. The MVP is "be able to drag a program to the terminal and run it", and the next feature, way down on the backlog is "allow the user to revoke permissions granted by dragged-in apps"
  - ryanianian 7y ago
    It's actually the result of product-owners deciding to release unfinished software, likely responding to incentives from management to ship (boolean) without clear standards about what is shippable (non-boolean).
    - saagarjha 7y ago
      I think you're trying to derive too much insight from a small change like this.
      - Wowfunhappy 7y ago
        I agree, but it's not an unfair comment in light of what a mess Catalina and iOS 13 have been as a whole.
    - neuronic 7y ago
      Software always is and always will be unfinished.

deleted 7y ago

[deleted]

chadlavi 7y ago

> because Millennials are killing Unix How is this our fault?

notatoad 7y ago
Everything is our fault. Haven't you been paying attention?
- chadlavi 7y ago
  I've been too busy eating avocado toast and taking out more student loans
  - deleted 7y ago
    [deleted]
  - reaperducer 7y ago
    "I eat Tide Pods and I vote."
- e40 7y ago
  According to my millennial son, boomers screwed up everything.
  - Ididntdothis 7y ago
    Exactly!
    - OrangeMango 7y ago
      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
  - entelechy0 7y ago
    Ok boomer

deleted 7y ago

[deleted]

samwillis 7y ago

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!

deleted 7y ago
[deleted]
Ididntdothis 7y ago
Can you trust users to understand what the permission prompts really mean? Its like UAC in Windows where most people just press “yes” all the time.
- klodolph 7y ago
  Exactly. This is why when you double-click on an arbitrary app you downloaded on macOS, there is no “yes” button. You have to bypass the protection by right-clicking on the app or by changing system settings. This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. I think this is the right choice!
  - strbean 7y ago
    I dislike the whole "Pop out the system settings dialog and enable things for the application" approach. It throws users into what is likely unfamiliar territory, which just obfuscates things further. I think a list of permissions with detailed explanations as to what they mean, and a Yes button, is a better approach. Although there needs to be an option to disable or even mock certain permissions.
    - Ididntdothis 7y ago
      Agreed. Especially since there is no explanation why the permission is needed and what it does in detail. I am a very experienced Windows dev but on my MacBook I have no idea what the exact implications are when an app requires access to “accessibility”. I am pretty sure the regular user doesn’t even have the foggiest idea but just does what he is told to do to make the app work. There is also no log what tells how the app uses the permission. It would be nice if there was a log of each use of the granted permission.

a1k0n 7y ago

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?

geoelectric 7y ago
Dumb question, of course, but you're logged in as aaaaaaa, right? That's what whoami returns?
- a1k0n 7y ago
  yes yes, it is owned by me. i edited my username in the "screenshot".
coldtea 7y ago
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 7y ago
  I think that's an emacs backup file. Does Vim also use the <filename>~ format too?
- a1k0n 7y ago
  i mv'd config to config~, then made a copy of it as config. the old file, now renamed to config~, is still read-only.

jiveturkey 7y ago

> It's well known I didn't know that! Lovely feature.

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

abtinf 7y ago

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 7y ago
> Keyloggers embedded in the default operating system (web search in windows start; Ubuntu web search; Siri web search. How exactly are these keyloggers?
- tenebrisalietum 7y ago
  They send each keypress in a search to a remote service who is able to log it.
  - saagarjha 7y ago
    I mean, how else do you expect web searches to work?
    - mr__y 7y ago
      I would expect them to send search the query if and when I search for something and send exactly nothing when I don't

cannam 7y ago

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 7y ago
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.
- saagarjha 7y ago
  The "sane UI" in this case is one that has already existed for years, and it's the user intent of dropping a file into an application to give it access.
  - djsumdog 7y ago
    I dunno. It makes me think of the Zen of Python's "Explicit is better than implicit." .. which is the point of the entire new Vista-style permission granting dialogues to begin with.
    - zerkten 7y ago
      Those dialogs recognized the product had to change significantly for the time and were accompanied by many changes below the surface. I'm not sure that the same level of recognition exists in Apple circles.

saagarjha 7y ago

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

jrochkind1 7y ago

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 7y ago
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 7y ago
  Can't forget the migration to APFS. For me that was reason alone to upgrade from Sierra.
- jrochkind1 7y ago
  okay, sure. :)

crazygringo 7y ago

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 7y ago
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.
- saagarjha 7y ago
  > The problem is that whoever implemented this change did not care to consider the full workflow lifecycle/consequences of enabling that change. Why do you think this is the case?
- floatingatoll 7y ago
  What if they did fully consider it, and reached a decision that you disagree with?
  - jerf 7y ago
    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.

sproketboy 7y ago

Reasons not to upgrade yet.

akerro 7y ago

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

jtaft 7y ago

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 7y ago
It should have been moved to a "Relocated Items" or "Previous System" folder, or something similar.
- jtaft 7y ago
  Interesting, thanks! They moved to /Users/Shared/Relocated Items .
- hanche 7y ago
  Indeed, on my mac I found such an item in the Desktop folder after upgrading.

c-smile 7y ago

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 7y ago
Try running xattr on the file in the terminal. It might include why it can’t open it
- c-smile 7y ago
  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 7y ago
    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.
deleted 7y ago
[deleted]

genimelineji 7y ago

AAAh

deleted 7y ago

[deleted]

fiddlerwoaroof 7y ago

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 7y ago
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 7y ago
  Hang on, Google and Dropbox are snooping around on the filesystem outside of their configuration or explicitly shared folders?
  - mindfulhack 7y ago
    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.
  - arh68 7y ago
    Yes maybe, at times, even Chrome: https://news.ycombinator.com/item?id=19653881 https://news.ycombinator.com/item?id=19653881
- 7y ago

deleted 7y ago

[deleted]

brown9-2 7y ago

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 7y ago
This is the entire goal behind sandboxing.

overgard 7y ago

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 7y ago
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 7y ago
  It's once per app that tries to access something restricted.

alanh 7y ago

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

EGreg 7y ago

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?

Quiark 7y ago

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?

ridaj 7y ago

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

Ericson2314 7y ago

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.

professorTuring 7y ago

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.

computerex 7y ago

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.

tinus_hn 7y ago

> because Millennials are killing Unix. This is where I closed the article.