2 ms·

>But what if you’re attempting to use those utilities against your real documents? You copy or move documents inside the specific sandbox. If you want a pipel

>But what if you’re attempting to use those utilities against your real documents? You copy or move documents inside the specific sandbox. If you want a pipeline, you establish a chain of inbox/outbox folders. Obviously, most of this should be done by the OS, not the user. The workflow: - You click "download" in your browser. - When it's done and you click on your download, the OS asks how you want to open it. Instead of "execute" option you get "run in a sandbox" option. - You type in the name of the sandbox, the app gets copies to /apps/sandboxName or something of that sort. - The system automatically creates /apps/sandboxName/inbox and /apps/sandboxName/outbox. - To process a file in some way, you drop it into inbox dir. For command line, the only change would be switching from "executable pulls arbitrary files" to "I push specific file to the executable". zip -r squash.zip dir1 becomes | -r squash.zip | zip dir1 | Start pipeline. Push squash.zip as an argument to zip, get the output. Zip would be the container name.

derefr 7y ago
Let me put it another way: how would you implement a dotfile management framework (like any of these: https://dotfiles.github.io https://dotfiles.github.io)? Programmers seem to really like them, judging by how many of them there are. But the whole point of them is to forcefully usurp the assets of literally every other program on the system. They're user-level rootkits, in a sense. Or, for a simpler, more obvious example: find(1), grep(1), etc. A set of utilities that can all be asked the equivalent of "read literally every file the VFS has access to and tell me whether they match an arbitrary-code-execution predicate." Do you want to literally copy your entire hard disk into the 'inbox' of these utilities, in order to get them to search it for you? (And before you say "well, we can trust the base utilities that ship with the OS to do more than arbitrary third-party utilities"—there's a whole competition of grep(1) replacements, e.g. ag(1), rg(1), etc. Do you want to make it impossible for people to innovate in this space?) Or how about Nix, or GNU Stow, or, uh, Git? These utilities become useless if they have their own sandbox. Does your git worktree live in Git's sandbox? Vi's sandbox? The inability to make this distinction functional is why mobile OSes only have fullly-integrated IDEs! Or how about shells themselves! (Or, equivalently, any scripting runtime, e.g. Ruby, Python, etc.) Should people not be allowed to install these from third parties? Or, the most based example of all: make(1) [and its spiritual descendants], and the GNU autotools built atop it. How does ./configure work if you can't detect true properties of the target system, only of the sandbox you're in?
- gambler 7y ago
  >"Do you want to literally copy your entire hard disk into the 'inbox' of these utilities, in order to get them to search it for you?" Well, let's think about the goal here. grep reads files and outputs lines from those files. It needs full read access to everything you want to search. It does not need write access outside of its sandbox. It does not need direct access to network sockets, audio stuff and so on. Is it unreasonable to create a readonly "view" of the filesystem inside grep's folder? Is it unreasonable to have "files" representing network access, microphone, audio? It will have visual representation in file manager without the need to create custom UI. It could be manipulated by drag-and-drop OR command line. More importantly: it's easy for users to understand. "This app lives in a box. You can put things in that box for the app to use." >Does your git worktree live in Git's sandbox? Yes? I mean, I currently have a folder called projects. All my git stuff is in there anyway. >Vi's sandbox? If you want multiple sandboxes to be able to operate on a directory, you create "views" for that directory (readonly or read/write) in multiple sandboxes. This shouldn't be some sort of mind-bending idea, considering Unix has symlinks, hardlinks, and mounted filesystems of all sorts. >Or how about shells themselves! (Or, equivalently, any scripting runtime, e.g. Ruby, Python, etc.) Should people not be allowed to install these from third parties? There is no reason why a Ruby executable should have unlimited access to the entire file system. Especially if you're only using it for a specific purpose, like serving a website. What I'm describing here isn't some novel, mind-blowing idea. It's simply dependency injection. With file-based user interface. Every single part of this had been done in various operating systems or programming environments more than once. It's just a matter of combining it all in a sensible way.
  - JetSpiegel 7y ago
    > It does not need write access outside of its sandbox. You have SElinux for that, if you like bureaucracy and filing triplicate forms to able to run scripts with side effects.

derefr 7y ago

Let me put it another way: how would you implement a dotfile management framework (like any of these: https://dotfiles.github.io https://dotfiles.github.io)? Programmers seem to really like them, judging by how many of them there are. But the whole point of them is to forcefully usurp the assets of literally every other program on the system. They're user-level rootkits, in a sense. Or, for a simpler, more obvious example: find(1), grep(1), etc. A set of utilities that can all be asked the equivalent of "read literally every file the VFS has access to and tell me whether they match an arbitrary-code-execution predicate." Do you want to literally copy your entire hard disk into the 'inbox' of these utilities, in order to get them to search it for you? (And before you say "well, we can trust the base utilities that ship with the OS to do more than arbitrary third-party utilities"—there's a whole competition of grep(1) replacements, e.g. ag(1), rg(1), etc. Do you want to make it impossible for people to innovate in this space?) Or how about Nix, or GNU Stow, or, uh, Git? These utilities become useless if they have their own sandbox. Does your git worktree live in Git's sandbox? Vi's sandbox? The inability to make this distinction functional is why mobile OSes only have fullly-integrated IDEs! Or how about shells themselves! (Or, equivalently, any scripting runtime, e.g. Ruby, Python, etc.) Should people not be allowed to install these from third parties? Or, the most based example of all: make(1) [and its spiritual descendants], and the GNU autotools built atop it. How does ./configure work if you can't detect true properties of the target system, only of the sandbox you're in?

gambler 7y ago
>"Do you want to literally copy your entire hard disk into the 'inbox' of these utilities, in order to get them to search it for you?" Well, let's think about the goal here. grep reads files and outputs lines from those files. It needs full read access to everything you want to search. It does not need write access outside of its sandbox. It does not need direct access to network sockets, audio stuff and so on. Is it unreasonable to create a readonly "view" of the filesystem inside grep's folder? Is it unreasonable to have "files" representing network access, microphone, audio? It will have visual representation in file manager without the need to create custom UI. It could be manipulated by drag-and-drop OR command line. More importantly: it's easy for users to understand. "This app lives in a box. You can put things in that box for the app to use." >Does your git worktree live in Git's sandbox? Yes? I mean, I currently have a folder called projects. All my git stuff is in there anyway. >Vi's sandbox? If you want multiple sandboxes to be able to operate on a directory, you create "views" for that directory (readonly or read/write) in multiple sandboxes. This shouldn't be some sort of mind-bending idea, considering Unix has symlinks, hardlinks, and mounted filesystems of all sorts. >Or how about shells themselves! (Or, equivalently, any scripting runtime, e.g. Ruby, Python, etc.) Should people not be allowed to install these from third parties? There is no reason why a Ruby executable should have unlimited access to the entire file system. Especially if you're only using it for a specific purpose, like serving a website. What I'm describing here isn't some novel, mind-blowing idea. It's simply dependency injection. With file-based user interface. Every single part of this had been done in various operating systems or programming environments more than once. It's just a matter of combining it all in a sensible way.
- JetSpiegel 7y ago
  > It does not need write access outside of its sandbox. You have SElinux for that, if you like bureaucracy and filing triplicate forms to able to run scripts with side effects.