3 ms·
The problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.
by Ar-Curunir 6y ago
The problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.
- gspr 6y agoNot saying it's perfect, but sure there is! https://en.wikipedia.org/wiki/POSIX https://en.wikipedia.org/wiki/POSIX for example.
- spicybright 6y agoDefinitely 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.
- Blikkentrekker 6y agoThat 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.
- Pxtl 6y agoThis. 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.
- pcr910303 6y ago> 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.)