4 ms·
Can we eliminate or reduce the need for permissions altogether? E.g. OSes have an `open()` system call, which can potentially access any part of the filesystem
by shalabhc 9y ago
Can we eliminate or reduce the need for permissions altogether?
E.g. OSes have an `open()` system call, which can potentially access any part of the filesystem, and then they layer an ever growing permission system to restrict this.
Can we design a system where there is no `open()` call at all? Instead, the program declares "I accept an image and output an image", and when it is invoked, the OS asks the user for an image, making it clear which program is asking for it. Then the OS calls the program, passing in the selected file.
This model has other advantages such as introspection, composability, validation and isolation (e.g. a program that declares it takes an image an output an image has no access to the network anyway and cannot send you image over the network.)
- irishsultan 9y agoI don't see how this would work for command line tools (there are other applications where an extreme version wouldn't work, but for command line tools I really don't see a good workaround except giving broad permissions).
- shalabhc 9y agoIf command lines were built in systems designed around this principle, they would work slightly different than what we're used to. For instance, when invoking this 'program' on the command line, the system would discover it needs an image and use the command line itself to ask for an image from the user. Alternatively there could be standard way to pass an image (or any other input) to a program - similar to a command line arg in current systems, for instance.
- irishsultan 9y agoI don't see how this works with something like a recursive grep, or a find result sent to xargs for further processing.
- shalabhc 9y agoYou would define rgrep as taking a stream of files. Generating the stream of files is outside the capability of any program (since we don't have `open` or even `listdir`). Instead you'd use a primitive of the storage system itself to define a stream of files that you pass to rgrep. Something like `rgrep(/my/path/, text)`. So it becomes impossible for any program to access a file without the user's explicit indication.
- irishsultan 9y agoThat still doesn't help with a find + xargs combination, or with any kind of problem where you can currently store file names in a file and use that for later processing.
- shalabhc 9y agoYou cant have a find program because you can't discover files, you must be provided them. But you can have a `filter` program, that takes a stream of files an outputs another stream of files matching a filter. You can then pipe the output of filter into another program. Yes you cannot store filenames, but you could store some other serialized token generated from a file and the token could be used to recreate the file object. Alternatively, if you have an image based system, you don't have to convert the file object to a token explicitly - you just hold the references to the file objects and they're automatically persisted and loaded.
- irishsultan 9y agoWait, so even listing file names needs permissions (otherwise find would work), even doing ls on the command line won't work?
- shalabhc 9y agoCorrect - ls couldn't be a separate program - it would be replaced with a primitive that lets you explore the filesystem. The point of such a system would be that programs cannot explore or read the filesystem as there is no filesystem API. But programs can operate on files explicitly given to them. So exploring the filesystem is restricted to some primitives that have to be used explicitly. The guarantee then is if I invoke a program without giving it a file or folder, I know it absolutely cannot access any file.