Initializing OPAM in a Chroot container

[brettgilio]

Hey all, I am trying to initialize OPAM inside of chroot using an unprivileged user. The chroot is running debian testing with opam 2.0.5 and bubblewrap 0.4.0.

When I try to initialize opam it fails with:

#=== ERROR while compiling ocaml-system.4.08.1 ================================#
# context     2.0.5 | linux/x86_64 |  | https://opam.ocaml.org#0978bce5
# path        ~/.opam/default/.opam-switch/build/ocaml-system.4.08.1
# command     ~/.opam/opam-init/hooks/sandbox.sh build ocaml gen_ocaml_config.ml
# exit-code   1
# env-file    /tmp/opam-xxx-3451/ocaml-system-3451-8b8a2d.env
# output-file /tmp/opam-xxx-3451/ocaml-system-3451-8b8a2d.out
### output ###
# bwrap: Can't read /proc/sys/kernel/overflowuid: No such file or directory

Fair enough. I will just mount my host system /proc to my chroot environment. But this returns a slightly different.

[ERROR] The compilation of ocaml-system failed at
        "/home/brettg/.opam/opam-init/hooks/sandbox.sh build ocaml
        gen_ocaml_config.ml".

#=== ERROR while compiling ocaml-system.4.08.1 ================================#
# context     2.0.5 | linux/x86_64 |  | https://opam.ocaml.org#0978bce5
# path        ~/.opam/default/.opam-switch/build/ocaml-system.4.08.1
# command     ~/.opam/opam-init/hooks/sandbox.sh build ocaml gen_ocaml_config.ml
# exit-code   1
# env-file    /tmp/opam-brettg-3516/ocaml-system-3516-8b8a2d.env
# output-file /tmp/opam-brettg-3516/ocaml-system-3516-8b8a2d.out
### output ###
# bwrap: Failed to make / slave: Invalid argument

Any ideas what the problem here is?

Edit: I am aware I can just --disable-sandboxing but I am explicitly trying to avoid that configuration.

[brettgilio]

Documentation/filesystems/ramfs-rootfs-initramfs.txt it is written:

Rootfs is a special instance of ramfs (or tmpfs, if that's enabled),
which is   
always present in 2.6 systems.  You can't unmount rootfs for
approximately the  
same reason you can't kill the init process; rather than having special
code    
to check for and handle an empty list, it's smaller and simpler for the
kernel  
to just make sure certain lists can't become empty. 

So mount --bind is not supposed to work on rootfs. Then I've wrote small
init script that creates real 'tmpfs' (as opposed to 'rootfs'), moves
system root there and then switch_root there. Now lxc-start works!
Cool! :)

https://lists.linuxcontainers.org/pipermail/lxc-devel/2013-October/005761.html

lxc instead of chroot, but likely the same issue

[rjbou]

As it is a bubblewrap issue, we rely on their bugtracker for this kind of things.
On the opam part, to handle this issue, there is this discussion #4089 to (semi-)automatically disable sandboxing when it is detected as unavailable.
We can use bwrap options, to handle specific configuration if needed too.
I'll ping @mato as he had the problem initially on a chroot, just in case he has some related information.

[mato]

Hi @brettgilio. If you're running opam in a chroot then until an implementation for #4089 lands my recommendation would be to just disable sandboxing at opam init time. Otherwise you're going to have to punch "holes" in the chroot anyway, which defeats the purpose of using it in the first place.

[avsm]

I am aware I can just --disable-sandboxing but I am explicitly trying to avoid that configuration.

Why? You've got another sandbox around the opam invocation, and Linux typically makes it pretty difficult to compose different sandboxes. I'll close this, as there's not much we can do much from within opam, but if there's a good reason to try to make nested sandboxing work, please do reopen.

[abliss]

FYI, I hit the same problem running bwrap inside a chroot. Composing bwrap and chroot is important to me, since I don't want the wrapped process to be able to access my entire chroot (especially since opam FAQ says "Makefiles that run rm -rf / do happen." ) AFAIK, the linux kernel does not make this particular composition of sandboxes difficult. I found a workaround on this issue, which claims (without evidence) that the issue is a bwrap bug: flatpak/flatpak#703 (comment) . By making the chroot's root directory a bind-mount of itself (before chrooting), bwrap can indeed work inside a chroot (I'm on linux 4.4.146 in case it matters).