document ways to enforce (linux) sandboxing
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the problem / feature request:
Bazel can silently fallback to weaker symlink sandbox if `/bin/ttue` is not available (https://github.com/bazelbuild/bazel/issues/13994) or if there aren't enough privileges to execute `clone` syscall with new namespaces (say running in unprivileged docker container locally or in cloud / CI).
This makes one's CI checks weaker and difference between build/test targets on different machines hidden. And since not all rules are sandbox-ready it'd be nice to have control over whether sandbox is on.
Ideally there should be flags to: best effort sandboxing, failing if sandboxing isn't working, disabling sandboxing, and also all of it for specific aspects (networking, root filesystem access, write access to inputs or other undeclared places, sandboxfs mounts availability, etc)
### Feature requests: what underlying problem are you trying to solve with this feature?
Have control over sandboxing to be more hermetic, consistent between machines and have reliable CI.
### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Run bazel in unprivileged docker container and execute an action that escapes the sandbox (no short example yet, may add later)
### What operating system are you running Bazel on?
> NixOS
### What's the output of `bazel info release`?
> release 4.2.1- (@non-git)
### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.
> NixOS nixpkgs
Contributor guide
Research direction
No source files or tests are named. Start by reproducing Bazel in an unprivileged Docker container and reviewing the sandbox behavior described in the issue, including fallback to symlink sandboxing. Done means documenting how to detect weaker sandboxing and control the requested sandbox capabilities.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, linux
- Domain
- build-system, infrastructure, operating-systems
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100