Running the sandbox on Centos 7 - kernel 3.8, 3.10, 3.12?!

[Dan Fabulich]

Centos 7 defaults to kernel version 3.10, but when I run bazel on it, it doesn't sandbox.

According to http://bazel.io/blog/2015/09/11/sandboxing.html the minimum supported kernel version is 3.8, but according to http://bazel.io/docs/bazel-user-manual.html#sandboxing the minimum supported kernel version is 3.12.

Is it possible to get the Bazel sandbox to work on Centos 7 without upgrading the kernel?

[Dan Fabulich]

Don't have Centos 7 handy? Here's a Vagrantfile you can use to download and launch Centos 7, install Bazel 0.2.3 and its dependencies, and run a quick genrule. Just install Vagrant https://www.vagrantup.com/downloads.html, put this Vagrantfile in an empty directory, and run "vagrant up". You can "vagrant ssh" to connect to the box as a sudoer.

https://gist.github.com/dfabulich/e7d7078c5bbf780e6ab14af98ac5a887

Actual: "WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed."

Expected: Sandbox

[Kamal Marhubi]

From this commit to Docker [0], it appears that you need to enable user namespaces (the kernel feature used by the sandbox) in your boot parameters. A comment on this RHEL blog post [1] gives exact commands to run:

In case someone else comes here from google trying to figure out how to use user namespaces on rhel/centos 7.2, you have to do `sudo grubby –args=”user_namespace.enable=1″ –update-kernel=/boot/vmlinuz-3.10.0-327.3.1.el7.x86_64` and then reboot to enable them. (obviously you have to change the kernel name if you’re running another kernel)

I wonder if the sandbox unsupported message could be more informative for common distros. I opened #1313 [2] for it.

[0] https://github.com/docker/docker/commit/23551515564b54128e882dda5eae659883947d39
[1] http://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/#comment-6796
[2] https://github.com/bazelbuild/bazel/issues/1313

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/b3c4881f-934b-4b5d-8332-ab1cad453ed9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Fabulich]

This gets me tantalizingly close, but not quite. It seems that "bazel build" uses the sandbox only when run as root, but when run as an ordinary user, it can't use the sandbox.

Here are my steps to reproduce:

1) Set up the Vagrantfile from here https://gist.github.com/dfabulich/e7d7078c5bbf780e6ab14af98ac5a887

2) vagrant up

This prints the "WARNING: Sandboxed execution is not supported" message in the Vagrant boot log.

3) vagrant ssh

4) sudo grubby --args="user_namespace.enable=1" --update-kernel=/boot/vmlinuz-3.10.0-327.13.1.el7.x86_64

5) exit

6) vagrant reload

Now, the Vagrant boot log does NOT show the warning.

7) vagrant ssh

8) bazel build //:x

"WARNING: Sandboxed execution is not supported"

9) sudo `which bazel` build //:x

No warning; works.

10) bazel build //:x

"WARNING: Sandboxed execution is not supported"

I'm a little confused about how/why it would ever work as non-root. http://man7.org/linux/man-pages/man2/clone.2.html says: "Only a privileged process (CAP_SYS_ADMIN) can employ CLONE_NEWNS."

But it obviously does work as a non-privileged user on Ubuntu, so I must be missing something…?

[Brian Silverman]

https://github.com/lxc/lxc/issues/842 looks potentially relevant (the conclusion there is that the kernel doesn't support it, unfortunately). In particular, verify that `unshare -U` works as not-root and see what `unshare -Um` as root and not-root does.

Also, on Debian kernels (Ubuntu too I think), you have to enable unprivileged user namespaces via /proc/sys/kernel/unprivileged_userns_clone; maybe yours has something similar, possibly just for mount namespaces?

On Wed, Jun 1, 2016 at 4:10 PM, Dan Fabulich <danfa...@gmail.com> wrote:

I'm a little confused about how/why it would ever work as non-root. http://man7.org/linux/man-pages/man2/clone.2.html says: "Only a privileged process (CAP_SYS_ADMIN) can employ CLONE_NEWNS."

But it obviously does work as a non-privileged user on Ubuntu, so I must be missing something…?

 It's using CLONE_NEWUSER too, which means the process has CAP_SYS_ADMIN (and all the other capabilities too I think) inside the namespace.