5 ms·

I 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

I 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 ago
If 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 ago
  I don't see how this works with something like a recursive grep, or a find result sent to xargs for further processing.
  - shalabhc 9y ago
    You 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 ago
      That 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 ago
        You 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 ago
        Wait, so even listing file names needs permissions (otherwise find would work), even doing ls on the command line won't work?
        shalabhc 9y ago
        Correct - 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.
        irishsultan 9y ago
        Define "explicitly", because if it means that I can't just type it in a shell then that disqualifies it from being a practical solution, and if I can't put it in a function/script that I can call from a shell that disqualifies it as well. But if I can do those things (especially the second), then that seems to open at least some attack vectors (that would obviously depend on the actual rules).

shalabhc 9y ago

If 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 ago
I don't see how this works with something like a recursive grep, or a find result sent to xargs for further processing.
- shalabhc 9y ago
  You 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 ago
    That 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 ago
      You 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 ago
        Wait, so even listing file names needs permissions (otherwise find would work), even doing ls on the command line won't work?
        shalabhc 9y ago
        Correct - 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.
        irishsultan 9y ago
        Define "explicitly", because if it means that I can't just type it in a shell then that disqualifies it from being a practical solution, and if I can't put it in a function/script that I can call from a shell that disqualifies it as well. But if I can do those things (especially the second), then that seems to open at least some attack vectors (that would obviously depend on the actual rules).