Aspect actions for unsandboxed targets also run unsandboxed (with `--incompatible_allow_tags_propagation`)
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
If I have a target which runs unsandboxed (e.g. a test with `tags = ["no-sandbox"]`), and I run an aspect on that target where the aspect contains an action, the aspect action also runs unsandboxed.
### Which category does this issue belong to?
Local Execution
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Create a simple aspect with an action and run it on an unsandboxed target. For example, this gist: https://gist.github.com/william-smith-skydio/1e4c008043713f0fc470c8d944ab5993
Run the aspect:
```
bazel build //:unsandboxed_test --aspects rules.bzl%reproducer_aspect --output_groups=aspect_out
```
Peek in `bazel-bin/unsandboxed_test.aspect_out` and observe that it contains all processes on your system. (I have truncated the output for privacy reasons.)
```
PID TTY TIME CMD
1341 ? 11:11:21 Isolated Web Co
1741 ? 00:00:42 rust-analyzer
1849 ? 3-06:56:05 Isolated Web Co
2176 ? 00:00:43 java
...
```
If the action were run in a sandbox, the sandbox's process namespace would limit the output to just a handful of processes used for the sandbox and the test itself. We can get back to this correct behavior by either removing `no-sandbox` from the test target or passing `--noincompatible_allow_tags_propagation`:
```
PID TTY TIME CMD
1 ? 00:00:00 linux-sandbox
2 ? 00:00:00 bash
3 ? 00:00:00 ps
```
### Which operating system are you running Bazel on?
Ubuntu 18.04
### What is the output of `bazel info release`?
release 7.0.2
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse HEAD` ?
_No response_
### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
This is caused by enabling `--incompatible_allow_tags_propagation`. This flag was enabled by default in bazel 7.x, but the same behavior can be reproduced in earlier bazel versions by setting `--experimental_allow_tags_propagation`.
### Have you found anything relevant by searching the web?
There are other open issues related to `--incompatible_allow_tags_propagation`, but I haven't found anything about this issue with aspects.
### Any other information, logs, or outputs that you want to share?
I'm not entirely convinced that this behavior is incorrect. It makes some kind of sense, but it's also very unexpected.
I discovered this due to flaky CI failures in the rules_rust clippy aspect when run on an unsandboxed test. It was sometimes failing when run unsandboxed due to a poor interaction with the `--@rules_rust//:rustc_output_diagnostics=true` flag. I am currently resorting to disabling running clippy on that test.
Contributor guide
Assessment
This issue has not been assessed yet.