Sandbox crates


#1

With no_std and an hypothetical no_unsafe and the ability to force these on dependencies in a non-transitive manner, we would be able to build sandbox crates… sort of.

This has a few issues tho:

  • no_std is currently transitive
  • the requirement of a support crate means the sandbox crate… doesn’t actually sandbox anything, and instead just maintains a global state consisting of a bunch of function pointers (effectively).

Both of these are slightly ugly, so instead I’d like something much more powerful: feature flags on stable and crates.

You see, feature flags don’t modify the code, unlike Cargo features. Instead, they just allow/disallow API usage by downstream crates. This is a much better system for a sandbox crate:

  • Rather than doing non-transitive no_std, we can tell the dependency that it’s only allowed to use specific parts of std: atomics, collections, Vec, Box, Arc, Rc, etc.
  • We still need a non-transitive no_unsafe.
  • We still need a way to disallow dependencies (besides the sandbox crate).
  • We can put the sandbox impl in the sandbox crate, behind an feature-flagged API. The dependency wouldn’t be able to access these APIs, but the host crate would. The sandbox crate would be built once, with all its APIs, but only a specific set of APIs would be visible to the dependency.

This would be really nice to have.


#2

Feature flags on std to disable I/O seems like a decent way to be able to sandbox some code.


#3

I want to control each part separately.


closed #4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.