option to disable sandboxing for certain binary targets/runs

[kevingessner]

I'd like to use bazel run in more situations than are currently supported. We have some tools in our Java codebase that are built with Bazel and do various utility operations, such as generating code for other repositories, formatting source files, or running ML model validation. It would be great to run these tools with bazel run, giving us a consistent CLI for running all manner of things in our codebase. However, sandboxing puts pretty strict limitations on what these tools can do. Since all inputs need to be in the BUILD file as a data dependency, a tool can't easily take additional inputs via command line arguments.

For instance, with a tool like the model validator that reads a text file, performs some operations on the contents, and writes results, users will often change the input on every run. That is, they might run bazel build tools/validator, then validator ~/tmp/input1.txt followed by validator ~/tmp/input2.txt. Here, bazel run tools/validator -- ~/tmp/input1.txt won't work -- if the input file is in the workspace, it will work with the unfortunate extra step of adding the input path as a data dependency the BUILD file before each run; if the input file is outside the workspace, even that isn't sufficient.

I've worked around this problem (as has bazel-deps) with a wrapper script, which uses bazel to build the binary than runs it directly from bazel-bin. That extra step isn't a huge pain, but all those wrapper scripts do add up. It'd be great to have an easy, fully-supported way of breaking out of the sandbox for individual binaries with bazel run, or another way of smoothly adding runtime dependencies for these sorts of executables.

Environment info

• Operating System: linux (centos), mac os
• Bazel version (output of bazel info release): release 0.5.1

Have you found anything relevant by searching the web?

Related issues about the run environment:

• java_binary picks an non-configurable working directory #2579
• bazel run child should run with bazel invocation's current directory #3325

[aehlig]

CC @ulfjack @damienmg @dslomov as that request implicitly also touches the interface question on how binaries built by bazel can be used.

[damienmg]

I don't understand, bazel run does not run inside the sandbox, the problem might be ~ is not being interpreted, bazel run tools/validator -- $HOME/tmp/input1.txt should work just fine.

[kevingessner]

@damienmg You're right! This is a problem of path expansion, plus the unexpected working directory described in #3325, leading to files not being found. The errors made it feel like sandboxing was getting in my way, but I think was just my confusion. Closing in favor of that other issue. Thanks!

[damienmg]

I think the issue was just a confusion. Since we have other issue about having run behave more unsurprisingly, maybe close this one?

…

On Fri, Jul 21, 2017, 9:01 AM Ulf Adams ***@***.***> wrote: blaze run never uses sandboxing, AFAICT, so I'm not sure what this request is about. Maybe it's confusing that Bazel is changing the working directory for run? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3417 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADjHf7V9MjWtQ-EQ9sI_TvrATN6NZcE3ks5sQEzCgaJpZM4OdNzi> .

[ulfjack]

It's already closed. I had it open from yesterday and didn't see that it was already closed.