Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--sandbox_block_path should ignore missing directories #4963

Open
greggdonovan opened this issue Apr 4, 2018 · 3 comments
Open

--sandbox_block_path should ignore missing directories #4963

greggdonovan opened this issue Apr 4, 2018 · 3 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug

Comments

@greggdonovan
Copy link
Member

Description of the problem / feature request:

When I add the following to my .bazelrc, I get failures when /search does not exist:

build --sandbox_block_path=/search
test --sandbox_block_path=/search

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

I would like to exclude a directory from being readable in the sandbox to prevent likely cases of loss of hermeticity. If this directory does not exist, Bazel should ignore the --sandbox_block_path entry.

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

Replace this line with your answer.

What operating system are you running Bazel on?

CentOS 7

What's the output of bazel info release?

release 0.10.0

Have you found anything relevant by searching the web?

My own StackOverflow question. :)

@jin
Copy link
Member

jin commented Apr 9, 2018

cc @philwo

@jin jin added untriaged team-Local-Exec Issues and PRs for the Execution (Local) team and removed category: sandboxing labels Jan 16, 2019
@jmmv
Copy link
Contributor

jmmv commented Jan 24, 2019

From my reading of the code, this is only an issue on Linux: we try to bind-mount these paths and their non-existence causes the failure. On macOS, we just use these paths to configure sandbox-exec and never try to access them so I think we don't fail there.

We should make the behavior consistent across platforms, document what this is in the flag description, and add a test.

@jmmv jmmv added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Jan 24, 2019
otan added a commit to otan-cockroach/cockroach that referenced this issue Oct 30, 2020
Requires a downgrade to bazel-3.6.0.

In combination with cockroachdb#56142, this will compile cockroach-short correctly
on linux machines.

However, there is a drawback -- /usr/lib/include is needed for linux to
work. As such, MacOS users who have proj_api.h will need to use
--sandbox_block_path (you cannot sandbox_block_path a path that does
not exist due to bazelbuild/bazel#4963. I will
send an email out shortly afterwards.

Release note: None
craig bot pushed a commit to cockroachdb/cockroach that referenced this issue Nov 2, 2020
56143: bazel: pin go1.13.14, fix rules_foreign_cc to latest version r=irfansharif,jlinder a=otan

Resolves #56060 

Release note: None

56150: bazel: fix build on ubuntu machines r=irfansharif,jlinder a=otan

Requires a downgrade to bazel-3.6.0.

In combination with #56142, this will compile cockroach-short correctly
on linux machines.

However, there is a drawback -- /usr/lib/include is needed for linux to
work. As such, MacOS users who have proj_api.h will need to use
--sandbox_block_path (you cannot sandbox_block_path a path that does
not exist due to bazelbuild/bazel#4963. I will
send an email out shortly afterwards.

Release note: None

Co-authored-by: Oliver Tan <otan@cockroachlabs.com>
@0xjc
Copy link

0xjc commented May 5, 2022

I'm still running into this issue on bazel 5.1.1. --sandbox_block_path seems really useful to prevent accidentally including headers from system packages, and it would be great if it could work regardless of whether or not the build host has the package installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug
Projects
None yet
Development

No branches or pull requests

5 participants