17 ms·

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,

by 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.
  - zerkten 7y ago
    Is this automatable with AppleScript, or similar? If so, then there are possibly some vectors that Apple are trying to block. There are likely many better ways to handle these situations, but I'm not sure I really expect it from the recent Apple. The most recent Apple is recognizing issues (i.e. MacBook Pro keyboard), but I doubt the whole organization has caught up.
    - saagarjha 7y ago
      What, dragging a file and dropping it onto an application to grant it access? I am not sure. I'd like to think that doing this programmatically would be locked down if it allows an application to extend their access without user consent.
      - zerkten 7y ago
        You'd like to think? Operating systems have had loads of vulnerabilities from features like this. There needs to be defense in depth.
      - williamDafoe 7y ago
        It's so darned important to skip the step of asking the user if they want to make the file world, group, or user readable. So darned! I bet the guy who invented this has a patent and is a vp by now ....
  - Wowfunhappy 7y ago
    I'm not a fan of what Apple has done in Catalina, but I don't think your take is completely fair. "For years", simply opening an app implicitly gave it access to most of the data on your hard drive. Regardless of whether you opened or dragged in a particular file. In Catalina, Apple wanted to restrict this. As a consequence, in the initial release of Catalina, you could drag a file from your desktop into your Terminal, but your Terminal would be unable to access the file. Which of course is terrible UX! So what Apple did in this update is give back the behavior you're describing: dragging a file into the Terminal implicitly grants the Terminal access. But unlike in old OS's, the Terminal doesn't suddenly get access to most of the other data on your hard drive as well. Unfortunately, in order to walk that fine line, Apple had to add an extra, undocumented file attribute. And because Apple policy is for anything TCC-related should be SIP-protected, that attribute is protected by SIP and cannot be manually edited. And because a UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either... Apple's intentions with all of this absolutely make sense. The problem is that good intentions don't matter if the execution is flawed.
    - saagarjha 7y ago
      I am talking about a very specific feature of the Powerbox that gives you a security scoped bookmark to access a resource, even if you are sandboxed: https://news.ycombinator.com/item?id=21828138 https://news.ycombinator.com/item?id=21828138
    - btown 7y ago
      > And because the UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either. Why would this be a complete nightmare? There's no way to override a permission that's been granted to your ancestor - so why shouldn't the OS be able to remove the flag when you remove the permission in Settings? Why shouldn't the OS be able to maintain the invariant between the permissions dialog and the on-disk representation, given that the on-disk representation can only be set by the OS? That's just sad.
      - Wowfunhappy 7y ago
        The OS can certainly remove the flag. I just can't imagine what the UI for that would look like in Settings, once you've dragged many hundreds of files into the Terminal over the course of using your computer for several months. You could put it in the individual file's get info pane, but more users open that pane than know what the Terminal is. This is the kind of setting you'd want to control via either the Terminal (ironically) or a third party app. But Apple has decided only Apple-supplied software with a UI is allowed to control TCC.
- heydabop 7y ago
  > 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.
  - deleted 7y ago
    [deleted]
  - jaredklewis 7y ago
    It’s not perfect but I think there is sound logic to to the way it works. My wife is a fairly average computer user, and she has not added any files outside those folders that are in the user directory by default (Downloads, Desktop, Documents, Pictures, etc...). I think it seems pretty logical that Documents or Pictures for most users will include more personal data that needs protecting than ~/.config or whatever.
    - shakna 7y ago
      ~/.local on the other hand will frequently include information that under a tighter permission system should not be accessed without approval. Things like my complete shell history can be found there.
      - dylan604 7y ago
        The fact that you are worried about your shell history proves you are not one of the average users.
        shakna 7y ago
        And? How is that relevant to the permission system? The average person doesn't need to care whether a file is executable or not.
yborg 7y ago
sudoers here I come!
- Hackbraten 7y ago
  How would the sudoers file help here?
  - ggm 7y ago
    No. The op means: now a non admin user can trivially get write permission on sudoers file and become root.
    - kccqzy 7y ago
      The usual UNIX permissions checking doesn't get bypassed, does it? This is additional.
      - ggm 7y ago
        I don't know. I'm not addressing the underlying problem and it's veracity, I'm addressing the semantic confusion of op's intent regarding edit of the sudoers file.
      - Izmaki 7y ago
        That would be insane.
      - yborg 7y ago
        Alas, this approach does not yield fruit for the traditional core Unix files such as in /etc, these are not exposed through the Finder interface. However there are a lot of potentially sensitive files that could be trivially replaced by modified versions if this tactic works everywhere, i.e. /System/Library/Security/authorization.plist
        saagarjha 7y ago
        > Alas, this approach does not yield fruit for the traditional core Unix files such as in /etc, these are not exposed through the Finder interface. ⇧⌘G in Finder, type in /etc and press enter.
saagarjha 7y ago
> we bung in a whole new capability for this It's not new.
madeofpalk 7y ago
I don't think this is by passing any permissions system. My understanding of how the new permissions system works is that dragging a file into an app grants access to that file. You drag an image into a Microsoft Word, and permissions is granted to access that file so it can insert it into the document. I think that's just what's happening.
- fingerlocks 7y ago
  This situation is different because a SIP protected file attribute is set on the dragged file. There is no UI to manage this behavior and it persists forever, unless SIP is disabled. As other commentators have noted, it reeks of last-minute-workaround to close what would otherwise be a high priority UI bug for the permissions dialogs.
m463 7y ago
Many times I drag and drop a path, then edit the path. There are few reasons to go to catalina.
- saagarjha 7y ago
  How is anything before Catalina better?
  - gpvos 7y ago
    Snow Leopard, 10.6, still is the best MacOS version (except for the fact that it's not supported anymore). Only minor improvements have been made since then, and many deteriorations.
    - saagarjha 7y ago
      Great, your terminal can now access everything on your system.
      - Wowfunhappy 7y ago
        That's exactly what I want on my system, thank you very much. I don't understand why there's no TCC kill switch, like there is for Gatekeeper and SIP. It's needed.
        saagarjha 7y ago
        That is clearly not what the original commenter wanted.
        Wowfunhappy 7y ago
        ...Who is the original commenter at this point? GP mentioned preferring Snow Leopard, which doesn't have TCC. Cannam and m463 didn't express a preference either way.
benfrancom 7y ago
Title should be updated to include MacOS. I was thinking Tomcat Catalina file....

by cannam 7y ago

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.
- zerkten 7y ago
  Is this automatable with AppleScript, or similar? If so, then there are possibly some vectors that Apple are trying to block. There are likely many better ways to handle these situations, but I'm not sure I really expect it from the recent Apple. The most recent Apple is recognizing issues (i.e. MacBook Pro keyboard), but I doubt the whole organization has caught up.
  - saagarjha 7y ago
    What, dragging a file and dropping it onto an application to grant it access? I am not sure. I'd like to think that doing this programmatically would be locked down if it allows an application to extend their access without user consent.
    - zerkten 7y ago
      You'd like to think? Operating systems have had loads of vulnerabilities from features like this. There needs to be defense in depth.
    - williamDafoe 7y ago
      It's so darned important to skip the step of asking the user if they want to make the file world, group, or user readable. So darned! I bet the guy who invented this has a patent and is a vp by now ....
- Wowfunhappy 7y ago
  I'm not a fan of what Apple has done in Catalina, but I don't think your take is completely fair. "For years", simply opening an app implicitly gave it access to most of the data on your hard drive. Regardless of whether you opened or dragged in a particular file. In Catalina, Apple wanted to restrict this. As a consequence, in the initial release of Catalina, you could drag a file from your desktop into your Terminal, but your Terminal would be unable to access the file. Which of course is terrible UX! So what Apple did in this update is give back the behavior you're describing: dragging a file into the Terminal implicitly grants the Terminal access. But unlike in old OS's, the Terminal doesn't suddenly get access to most of the other data on your hard drive as well. Unfortunately, in order to walk that fine line, Apple had to add an extra, undocumented file attribute. And because Apple policy is for anything TCC-related should be SIP-protected, that attribute is protected by SIP and cannot be manually edited. And because a UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either... Apple's intentions with all of this absolutely make sense. The problem is that good intentions don't matter if the execution is flawed.
  - saagarjha 7y ago
    I am talking about a very specific feature of the Powerbox that gives you a security scoped bookmark to access a resource, even if you are sandboxed: https://news.ycombinator.com/item?id=21828138 https://news.ycombinator.com/item?id=21828138
  - btown 7y ago
    > And because the UI for revoking access to individual files would be a complete nightmare, there's no UI pathway either. Why would this be a complete nightmare? There's no way to override a permission that's been granted to your ancestor - so why shouldn't the OS be able to remove the flag when you remove the permission in Settings? Why shouldn't the OS be able to maintain the invariant between the permissions dialog and the on-disk representation, given that the on-disk representation can only be set by the OS? That's just sad.
    - Wowfunhappy 7y ago
      The OS can certainly remove the flag. I just can't imagine what the UI for that would look like in Settings, once you've dragged many hundreds of files into the Terminal over the course of using your computer for several months. You could put it in the individual file's get info pane, but more users open that pane than know what the Terminal is. This is the kind of setting you'd want to control via either the Terminal (ironically) or a third party app. But Apple has decided only Apple-supplied software with a UI is allowed to control TCC.
heydabop 7y ago
> 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.
- deleted 7y ago
  [deleted]
- jaredklewis 7y ago
  It’s not perfect but I think there is sound logic to to the way it works. My wife is a fairly average computer user, and she has not added any files outside those folders that are in the user directory by default (Downloads, Desktop, Documents, Pictures, etc...). I think it seems pretty logical that Documents or Pictures for most users will include more personal data that needs protecting than ~/.config or whatever.
  - shakna 7y ago
    ~/.local on the other hand will frequently include information that under a tighter permission system should not be accessed without approval. Things like my complete shell history can be found there.
    - dylan604 7y ago
      The fact that you are worried about your shell history proves you are not one of the average users.
      - shakna 7y ago
        And? How is that relevant to the permission system? The average person doesn't need to care whether a file is executable or not.

yborg 7y ago

sudoers here I come!

Hackbraten 7y ago
How would the sudoers file help here?
- ggm 7y ago
  No. The op means: now a non admin user can trivially get write permission on sudoers file and become root.
  - kccqzy 7y ago
    The usual UNIX permissions checking doesn't get bypassed, does it? This is additional.
    - ggm 7y ago
      I don't know. I'm not addressing the underlying problem and it's veracity, I'm addressing the semantic confusion of op's intent regarding edit of the sudoers file.
    - Izmaki 7y ago
      That would be insane.
    - yborg 7y ago
      Alas, this approach does not yield fruit for the traditional core Unix files such as in /etc, these are not exposed through the Finder interface. However there are a lot of potentially sensitive files that could be trivially replaced by modified versions if this tactic works everywhere, i.e. /System/Library/Security/authorization.plist
      - saagarjha 7y ago
        > Alas, this approach does not yield fruit for the traditional core Unix files such as in /etc, these are not exposed through the Finder interface. ⇧⌘G in Finder, type in /etc and press enter.

saagarjha 7y ago

> we bung in a whole new capability for this It's not new.

madeofpalk 7y ago

I don't think this is by passing any permissions system. My understanding of how the new permissions system works is that dragging a file into an app grants access to that file. You drag an image into a Microsoft Word, and permissions is granted to access that file so it can insert it into the document. I think that's just what's happening.

fingerlocks 7y ago
This situation is different because a SIP protected file attribute is set on the dragged file. There is no UI to manage this behavior and it persists forever, unless SIP is disabled. As other commentators have noted, it reeks of last-minute-workaround to close what would otherwise be a high priority UI bug for the permissions dialogs.

m463 7y ago

Many times I drag and drop a path, then edit the path. There are few reasons to go to catalina.

saagarjha 7y ago
How is anything before Catalina better?
- gpvos 7y ago
  Snow Leopard, 10.6, still is the best MacOS version (except for the fact that it's not supported anymore). Only minor improvements have been made since then, and many deteriorations.
  - saagarjha 7y ago
    Great, your terminal can now access everything on your system.
    - Wowfunhappy 7y ago
      That's exactly what I want on my system, thank you very much. I don't understand why there's no TCC kill switch, like there is for Gatekeeper and SIP. It's needed.
      - saagarjha 7y ago
        That is clearly not what the original commenter wanted.
        Wowfunhappy 7y ago
        ...Who is the original commenter at this point? GP mentioned preferring Snow Leopard, which doesn't have TCC. Cannam and m463 didn't express a preference either way.

benfrancom 7y ago

Title should be updated to include MacOS. I was thinking Tomcat Catalina file....