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.
This is why Google is forcing everyone to go through SAF, even though it is available since Android Android 4.4.
After the outcry to remove direct file access on Android 10, they decided to give one more version for devs to adapt to it, but it is coming on Android 11 no matter what.
And the old style access on Android 11 are just wrappers on top of SAF, which makes it even slower than using SAF directly.
On Windows, while UWP sandbox on its own might not have won lots of friends, with MSIX sandbox model for UWP/Win32 and the upcoming picosandboxes in Windows 10X also for UWP/Win32, these direct file APIs might eventually be a thing of the past, even if it still takes a couple of years to get there.
Ah and Linux applications on ChromeOS only sees what the hypervisor/gVisor allow them to see.
Wait, does that mean that programs like FTP server[0] wont work anymore? I use that very often to transfer files from my file manager to and from my phone (e.g. capture a video).
Or there is a way to bypass that and have access to the underlying FS?
That doesn't sound like something that would ever work for something like an FTP server. I think i'll stick with my current phone for the foreseeable future, until some workaround is found.
> 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.
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.
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.
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.