5 ms·

Just the ability to access the rest of the file system I think I wish was on a folder by folder basis. My text editor for example, I personally wouldn't mind i

Just the ability to access the rest of the file system I think I wish was on a folder by folder basis. My text editor for example, I personally wouldn't mind if once per project I had to give it permission to access a project's folder. I also wish there was a way to edit a file without giving access to the folder. For example Photoshop, I can select from the finder "Open In Photoshop" which is enough intent to give the app permission to access that file without having to give it access to the other files in the same folder. I get that would require API changes and that Apple doing that overnight would break apps but basically going forward I wish OS makers would work toward something like that. Even on iPhone I hate that apps either get permission to read all photos or none. Yes I get you can send a photo to an app but many apps can not receive them for every use. I get the apps want to present their own UI for the photos. Maybe some kind of OS run sandboxed process where the app can provide a limited function to present thumbnails but can't actually read any data and all they get out of that process from the OS is the user selected files? Oh well, I can dream.

ddrt 7y ago
Completely agree and you put this perfectly.
szc 7y ago
The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny. For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory. The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.
- saagarjha 7y ago
  > What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Powerbox actually has support for this.
  - sammorrowdrums 7y ago
    Surely it can store files in a working folder of its own, and keep a reference to the original file. The other files don't need to live side-by-side
    - justmedep 7y ago
      There is official support for auxiliary files in macOS/sandbox. A prime example is the use of SQLite in WAL mode which requires write access to $dir/my_db.sqlite + a bunch of other files in the same directory (for transaction handling etc). But this problem was solved years ago already because Core Data (an apple framework) actually uses SQLite under the hood.
    - szc 7y ago
      Absolutely, but this then means if apps want to adopt some sort of sandboxing, they will quite possibly have to adopt or obey some rules. Sometimes app developers will refuse. Being pragmatic, what can be done then? Observing the system calls apps make can be eye-opening and sometimes very sad.
  - szc 7y ago
    Sure. But does / did Photoshop have its own custom file picker? Some apps or multi-platform frameworks (like QT) have rolled their own in the past.
    - saagarjha 7y ago
      No idea about Photoshop, but yes, I have heard of custom file pickers being nonfunctional inside of sandboxed applications.
zimpenfish 7y ago
> I get the apps want to present their own UI for the photos. If it were up to me and my 100k photo library, none of those apps would pass App Store validation because they are inevitably a miserable experience. Even the OS photo picker isn't 100% jank-free on that number of photos but it at least works effectively unlike everyone who implements their own (takes 30s to appear, photos in random* order, albums in random* order, smart* albums missing, extraneous albums, etc.) > I hate that apps either get permission to read all photos or none I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. But that would be a great thing.
- saagarjha 7y ago
  > I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. It exists (https://developer.apple.com/documentation/uikit/uiimagepickercontroller https://developer.apple.com/documentation/uikit/uiimagepicke...) but apps don’t want to use it.
kalleboo 7y ago
I thought that was already how the macOS sandbox worked? The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps) https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW4 https://developer.apple.com/library/archive/documentation/Se... > When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app. > If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app. Starting in Catalina, even unsandboxed apps have gotten locked down a bit - you get permissions dialogs if they try to access Documents, Downloads or Desktop. The exploit in the OP is using an open, world-writable directory (/Users/Shared) since it can't access user files

ddrt 7y ago

Completely agree and you put this perfectly.

szc 7y ago

The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny. For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory. The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.

saagarjha 7y ago
> What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Powerbox actually has support for this.
- sammorrowdrums 7y ago
  Surely it can store files in a working folder of its own, and keep a reference to the original file. The other files don't need to live side-by-side
  - justmedep 7y ago
    There is official support for auxiliary files in macOS/sandbox. A prime example is the use of SQLite in WAL mode which requires write access to $dir/my_db.sqlite + a bunch of other files in the same directory (for transaction handling etc). But this problem was solved years ago already because Core Data (an apple framework) actually uses SQLite under the hood.
  - szc 7y ago
    Absolutely, but this then means if apps want to adopt some sort of sandboxing, they will quite possibly have to adopt or obey some rules. Sometimes app developers will refuse. Being pragmatic, what can be done then? Observing the system calls apps make can be eye-opening and sometimes very sad.
- szc 7y ago
  Sure. But does / did Photoshop have its own custom file picker? Some apps or multi-platform frameworks (like QT) have rolled their own in the past.
  - saagarjha 7y ago
    No idea about Photoshop, but yes, I have heard of custom file pickers being nonfunctional inside of sandboxed applications.

zimpenfish 7y ago

> I get the apps want to present their own UI for the photos. If it were up to me and my 100k photo library, none of those apps would pass App Store validation because they are inevitably a miserable experience. Even the OS photo picker isn't 100% jank-free on that number of photos but it at least works effectively unlike everyone who implements their own (takes 30s to appear, photos in random* order, albums in random* order, smart* albums missing, extraneous albums, etc.) > I hate that apps either get permission to read all photos or none I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. But that would be a great thing.

saagarjha 7y ago
> I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. It exists (https://developer.apple.com/documentation/uikit/uiimagepickercontroller https://developer.apple.com/documentation/uikit/uiimagepicke...) but apps don’t want to use it.

kalleboo 7y ago

I thought that was already how the macOS sandbox worked? The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps) https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW4 https://developer.apple.com/library/archive/documentation/Se... > When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app. > If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app. Starting in Catalina, even unsandboxed apps have gotten locked down a bit - you get permissions dialogs if they try to access Documents, Downloads or Desktop. The exploit in the OP is using an open, world-writable directory (/Users/Shared) since it can't access user files