Scoped file systems and read-only snapshots #81
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch properly introduces the idea of scoped file systems in Crochet, which means that each package is entirely isolated from each other. It also introduces the idea of pluggable backends for each scope. The pluggable backends are necessary for a related optimisation: bundled files for reducing network latency when Crochet projects are delivered over the web.
There's still a lot of work necessary to make this work securely, however. The new mechanism makes all of the standard library packages an archive file, and then uses an integrity hash when deciding to make them trusted. However, Crochet does not control what files are being distributed, so an attacker could still forge an archive of a standard library package with a matching hash and get native powers for free. This can be better addressed by packaging the TCB in the distribution itself, such that only those get trusted powers. But that'll be left as a follow up.
Scoped file systems also gate access for restricted writing to the underlying storage. This does not tackle the problem of application-specific storage yet (also something that will need to happen in a future PR). But it makes things a bit easier to follow than the previous approach of... passing absolute paths all over. Some good refactoring is still in order here.