bazel: Bazel sandboxing not supported WSL

Description of the problem / feature request:

I would like to build a codebase that uses sandboxing on the Windows Sybsystem for Linux.

Feature requests: what underlying problem are you trying to solve with this feature?

Whenever I try to build something, bazel throws the error: java.lang.IllegalStateException: com.google.devtools.build.lib.actions.UserExecException: Sandbox is not supported

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Install the Ubuntu WSL on Windows 10
Download and install bazel
Try to build in a project that uses the sandboxing feature

What operating system are you running Bazel on?

Windows 10, 1709

What’s the output of `bazel info release`?

201711232100+e0fe5d9

What’s the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

https://nbalch@…/gerrit/a/… ecb118d249b64b785a04d44225a573207de6a30a ecb118d249b64b785a04d44225a573207de6a30a

The two elipsis above are there to hide the server address. The proper remote shows up in reality.

Have you found anything relevant by searching the web?

I have tried to search other places on the web, but I haven’t found anything like this yet.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15 (8 by maintainers)

Most upvoted comments

@philwo We are passing in --spawn_strategy=linux-sandbox to explicitly disable that feature 😛 I don’t really want to deal with code ending up on the robot built without sandboxing and any bugs that could come from that. @neilbalch, you can make a local modification to build, but please don’t deploy to real hardware with that flag.

AustinSchuh on Feb 16, 2018

@philwo And you said you can’t reproduce this error on another WSL installation?

No, I haven’t tried yet to reproduce it myself. I just couldn’t see where that error might come from, from looking through the sandboxing code. But @AustinSchuh said that you were running a custom version of Bazel, so that explains it 😃

ERROR: /home/neil/971-Robot-Code/aos/downloader/downloader.bzl:37:13: function ‘depset’ does not exist.

depset was introduced in Bazel 0.7.0 (I think, at least its release notes mention it), so it looks like your Bazel version is too old. Can you try upgrading Bazel in your WSL?

After talking with @brian-peloton, it seems likely that the issues with WSL and sandboxing support stem from an improper implementation of unshare. Is this mendable by us or is this a limitation that must be resolved by the WSL team?

I was about to write a long reply regarding why this could never work in WSL and that unshare with all these namespace is such a complex feature that they probably would never get it to work, and then I found https://github.com/Microsoft/WSL/issues/2242#issuecomment-318864458. Wow. It looks like this might actually work (but require some development and testing effort on the linux-sandbox code to ensure we’re only using namespace features that work).

I won’t be able to work on this in the short-term, but that’s pretty exciting! If someone wants to give it a try, I’m happy to review pull requests for this.

For now, I would recommend to try building without sandboxing (bazel build --spawn_strategy=standalone --genrule_strategy=standalone //my:target) or the lightweight sandbox variant which doesn’t rely on any special kernel features: bazel build --spawn_strategy=processwrapper-sandbox --genrule_strategy=processwrapper-sandbox //my:target. Our official Bazel releases should automatically pick the processwrapper-sandbox strategy when linux-sandbox isn’t available, so you can try running with no flags after upgrading your Bazel and it should just work.

philwo on Feb 16, 2018

@neilbalch This is a custom patch we have at robotics. If you pull the latest version, we have upgraded bazel and switched to using a hard-coded spawn strategy per @philwo 's advice in another ticket. The code isn’t really set up to build outside the sandbox.