More likely, you want to temporarily give them permission to specific files you indicate. A graphical editor doesn’t have reason to read any file that the user didn’t explicitly picked for editing/viewing.
That’s how Mac OS works nowadays (possibly except for the ‘temporarily’; I don’t know the details): applications can only open files that the user selected in the system file open dialog. That runs in a separate process and opens up an app’s sandbox to allow access to the file the user selected.
In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access.[2][3] This can be used to implement a rudimentary form of capability-based security.
https://linux.die.net/man/7/unix
SCM_RIGHTS
Send or receive a set of open file descriptors from another process. The data
portion contains an integer array of the file descriptors. The passed file
descriptors behave as though they have been created with dup(2).
Other nifty thing with UNIX sockets is that you can just... read which user sent the message and as it is kernel adding that metadata you're 100% sure it came from that user. That's for example how you can set postgresql so say a certain user in the system can log as themselves without having to have a password.
> The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog.
> The selected files will be made accessible to the application via the document portal, and the returned URI will point into the document portal fuse filesystem in /run/user/$UID/doc/.
[1]: https://docs.flatpak.org/en/latest/portal-api-reference.html...
The problem is not isolation or lack of it. The problem is that app require complex set of permissions for both users files and other apps.
App might want to send notification to notification daemon. But app should not be able to pretend to be another app, whether by name or icon. And good luck trying to stop malicious app from just making same/similar enough icon and spelling Firefox with some fancy UTF characters to go around it.
And that's pretty simple case! And already very hard on kernel/OS level to solve. Now look at files.
You might want to allow graphical editor to open any graphical file, regardless of location.
You might want to allow that same editor to only edit some of them.
But for browser, you might want to allow saving new files, but not editing/rewriting existing ones, because it is not an editor, and should have no business editing the files.
Or, allow browser tab browsing certain URL (say, web image editor) to modify the files, but not the image sharing webpage that only needs to read the file.
Now we not only have insanely granular permissions per app, the different actions from "app" (web browser is basically container for multiple applications at that point) also need different permissions.
It has nothing to do with "unix bad", or "unix wrong", to actually separate the applications without hardships on the user (like fucking with permissions every time one app needs to touch files of another app) is just very very hard