Architecture rewrite

[insanitybit]

Currently the way things work is:

• Container is created for a project
• Container has a bindmount for the project directory
• 'init' process for container is sleep infinity
• Commands execute via docker exec api

Some problems that arise from this approach:

• Containers hang around indefinitely, although that shouldn't much impact performance
• The bind mounts have passthrough to the host, which means attacker controlled data is in the project's directory. Not a direct bypass, but definitely a security smell

A new approach should strive to resolve the above issues, as well as:

• Consider a future where controlled sharing across containers (both within and across a project) may be desirable
• Aim for an idiomatic approach
• Consider implications for non-Linux platforms

[insanitybit]

Currently there's a Build and Publish container, the idea being that they each have their own needs. I think this can actually be generalized to a sort of RW^X model.

For example, Build has execution rights so we want to minimize its read/write permissions (especially around access to sensitive areas of the file system, environment variables, crates.io tokens, source code, etc).

Publish, on the other hand, may have read/write capabilities (signing keys, crates.io token) but no execute (we don't run build scripts, etc).

This means that cargo-sandbox publish should be safe even though we share a cache across these two systems. But only if we're very careful to ensure that there's no execution in the cargo publish.

[insanitybit]

It's also probably fine to say that "cargo publish is an advanced case and cargo-sandbox's attempt to isolate the api key is best-effort, ultimately it's the rest of the host we want to protect".

[insanitybit]

There should be a "priming" step, ie: cargo --version, which will have read/write access to the cargo bin/ directory.