This. I would expect a modern permissions model to be:
App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
Possibly something more liberal could be granted for read permissions for like a gallery app or a music library thing, but that's what I'd expect for write permissions.
> temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.
Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)
Definitely not perfect, but I wish people would lean on good old fashion unix more for these things instead of implementing it worse on top of it.
I skimmed the article and it looks like one thing they do is have a daemon in the background to intercept data in and out, when they could just make user groups and normal file permissions.
I know it's almost a meme at this point, but plan9 had a great system for this.
You were able to define a filesystem layered on top of your own, exposing and linking files/folders however you please to any process.
So say you have a web server. You can make a layer that only has /www and /configs, linked to some folder in /var/foo/webstuff, and /etc/fooserver/configs or something.
No reason why you couldn't standardize an interface for systems like flatpak to safely use your filesystem.
That is because it turns out that everyday software often needs such permissions to operate gracefully.
What is wanted is some system that allows one to run untrusted sofware in without fear of it compromising one's system. — the problem is that the set of software that can be so ran is smaller than expected, as most software by design is capable of making changes to one's system, as one typically uses software for such tasks.
A text editor that cannot edit every file in one's home directory would be rather useless, but in doing so, it is of course capable of completely destroying one's system as well.
The dream of being able to run “entrusted software” is not a very realistic one.
