Support block-network by default for tests

[gorset]

We would like a way to enable network sandboxing by default. Currently this can only be enabled by adding the block-network tag to every test, which is error prone and cumbersome.

We have a bunch of tests that can crash when multiple tests accidentally binds to the same port. This is not the common case, but happens often enough to be annoying.

Adding block-network tag solves this on linux, but fails on macos with java.net.SocketException: Operation not permitted. See #2669 for more details for sandboxing problems with macos.

Support for a bazel startup flag would make it possible for us to run with block-network as default on linux machines and avoid any issues with macos.

Relevant code from the current master:

bazel/src/main/java/com/google/devtools/build/lib/sandbox/SandboxHelpers.java

Lines 144 to 152 in 7a38e27

	/** Returns true if this specific spawn requires network access. */
	static boolean shouldAllowNetwork(Spawn spawn) {
	// If the Spawn requests to block network access, do so.
	if (spawn.getExecutionInfo().containsKey("block-network")) {
	return false;
	}
	// Network access is allowed by default.
	return true;

[ittaiz]

@gorset have you considered the option of using a "remote-local" worker using docker? That should fix the macos problem.
It will still leave the problem of having to specify this tag on each test.
@philwo are there still substantial costs for using block-network? If not I think I'd also like to be able to turn it on by default

[philwo]

@ulfjack This might be a use case for our generic "--execution_info" flag, so that @gorset could just use something like --execution_info=TestAction+=block-network (exact flag syntax to be discussed) to make this the default for their setup.

@ittaiz I haven't checked the most recent Linux kernels whether they solved the performance problem or not - unfortunately there's nothing on the Bazel side that we can do.

For long-running tests it might not be too bad anyway - it was mostly an issue when using it as the default and then running a highly parallelized build consisting of many small actions.

I'd just give it a try.

[evanj]

FYI: I did a bit of research about this Linux kernel issue: This issue was at least improved in 4.12. There was a discussion on an unrelated Github issue, which led me to a LKML discussion in April 2017, which led to a patch that was included in 4.12 AFAICS. It may be worth attempting to re-evaluate this cost on recent versions of Linux?

Even without that: I would also like a flag to add this tag, so targets have to "opt out." Its so easy to create tests that accidentally depend on the network, which is not only flaky, but in some cases dangerous (e.g. if a developer runs a unit test that accidentally can talk across a network using the user's own credentials, which happens with the Google Cloud APIs for example).

[AustinSchuh]

Take a look at the --experimental_sandbox_default_allow_network flag. It allows you to change the default.

[susinmotion]

It looks like this is fixed based on the comment above. Please reopen if you are still having issues here.