[voltagex_]

Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

[AnthonyMouse]

> It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.

[comex]

Well, Flatpak is designed for GUI applications, where the user indicates their intent to grant access to a file by picking it the file chooser (which is magic, runs outside the sandbox, and grants the sandbox access to whatever file the user picked). This is nice because the sandbox can be invisible from the user’s perspective. I think AppV is similar.

For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames. Still, you can do reasonably well by just granting access to any argument that looks like a filename. The Plash shell, a forerunner of modern sandbox designs, took this approach, but as an additional security measure only granted read access by default; if you wanted to run a command that writes to a file, you had to use special syntax before the filename [1]. Still reasonably usable, although there are other issues, like the fact that many Unix programs default to reading and/or writing to the current directory…

[1] http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-d...

[AnthonyMouse]

> Well, Flatpak is designed for GUI applications, where the user indicates their intent to grant access to a file by picking it the file chooser (which is magic, runs outside the sandbox, and grants the sandbox access to whatever file the user picked). This is nice because the sandbox can be invisible from the user’s perspective.

That works where it works, but it seems like the sort of thing that will cause so much trouble that people end up turning it off. For example, a lot of files come with meta files containing thumbnails or other data with the same name but different extensions, or an associated directory with related data, and the app will want to access those too but a framework that doesn't understand they're related won't provide it.

You also end up with lots of little bugs, like breaking apps that predict what file you might open next and pre-load it or generate their own previews of files in the app's format.

A possible fix is that if the app tries to access a file you didn't expect it to, display an access prompt. But if that happens a lot it only conditions the user to just click yes every time.

> For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames.

You also don't know what's implied. Most commands default to operating on the current directory when not otherwise specified (e.g. as the output location for a tar extract), but half the time that's the root of the user's home directory.