Perfect Sandboxing in Bazel
summary
Migrating a 20‑year codebase to Bazel exposes tools that use absolute host paths, so the Bazel sandbox is extended to detect external symlinked inputs (via new_local_repository), traverse symlink chains and automatically turn those inputs into bind mounts under the Hermetic Linux sandbox. A spidering tool emits .bzl graphs of shared objects and POSIX binaries, the sandbox recreates symlinks or overlays and the build becomes hermetic in practice, with examples needing as few as five mounts.
AI-written summary · about
chapters (19)
- 0:00Sandboxing in Bazel
- 1:05Absolute paths break correctness
- 2:08How Bazel sandboxing works
- 5:41Correctness issue with absolute paths
- 6:44Fixing paths with repository rules
- 8:31Limitations of Hermetic Linux sandbox
- 10:39Tool consumption vs sandbox exposure
- 12:06Mounting absolute paths manually
- 13:13Extending Hermetic Linux sandbox
- 15:46Integrating changes seamlessly
- 17:58Practical usage and exemptions
- 18:40Modeling system dependencies
- 20:04Shared objects and binary dependencies
- 21:55Shell and POSIX dependencies
- 23:20Language package dependencies
- 24:24Takeaways and when to use
- 25:08Contrasting hermeticity methods
- 27:14Stronger guarantees without deep tool understanding
- 27:57Q&A
related talks
42mIntegrating with ease: Leveraging BuildStream interaction with Bazel build
28mIntegration testing with Bazel
11mLightning Talk – Testing Bazel’s Remote Execution API
46mBuilding Self Driving Cars with Bazel
49mFast and Furious
09mLightning Talk – Building Eclipse Plug-Ins (and OSGi Bundles) with Bazel
01h 01mTraceability and Automation Examples With Basil
45mSelective Testing + Q&A