How to properly sandbox ld.so for tests built with bazel?

25 views
Skip to first unread message

Alexander Szakaly

unread,
Aug 26, 2024, 10:02:21 AMAug 26
to bazel-discuss
Hi,
tl;dr: When including core libraries such as libc, libpthread etc in the sandbox for test execution there still seems to be no mechanism to ensure that also the dynamic linker (ld.so) is used from the sandbox. A version mismatch between libc and ld.so is an error. Background: Due to reasons we need to use a somewhat old gcc (9.4) and the toolchain repo contains also libc.so, ld-linux-x86.64.so.2 as well as some core libraries as libpthread, libdl etc. In the toolchain definition we include these libraries in the sandbox and provide an RPATH to the linker pointing to the place in the sandbox where those libraries are stored. Issue: The interpreter path stored in the ELF (INTERP) does not obey RPATH since it is the kernel that loads ld.so. AFAICT, the INTERP has to be a fixed absolute path on linux so there seems to be no way of fixing this via linker flags. Loading libc however does obey RPATH so when this is set via the linker to use a sandboxed libc there will be a mismatch between version of libc and ld.so which is an error. So for my actual question: Is there any known way to sandbox core libraries in a consistent way, meaning that also ld.so gets properly sandboxed and loaded from the sandbox so that there is no version mismatch? A potential idea to fix this given the limitations of INTERP would be to implement a mechanism in bazels test-wrapper (test-setup.sh) so that if there is a sandboxed ld.so it will be invoked explicitly such as $ <path_to_sandboxed_libs>/ld.so mytest_binary In that case one would have to refrain from using RPATH and instead have the test-wrapper set LD_LIBRARY_PATH to the sandboxed core libraries or some other similar mechanism. Since it is implemented in the test-wrapper one would achieve that when the test is run through 'bazel test' the test runs using the sandboxed core libraries but when running the test binary standalone it will use the core libraries from the host. In both cases will the version of libc and ld.so be consistent.

Or is there currently already an established mechanism to sandbox core libraries and ld consistently?

Best regards,
// Alexander

Fabian Meumertzheim

unread,
Aug 26, 2024, 11:14:54 AMAug 26
to Alexander Szakaly, Tom Rybka, bazel-discuss
For cc_test, you could register a custom test toolchain to inject a wrapper that uses the correct linker. I did something similar for musl in https://github.com/bazel-contrib/musl-toolchain/commit/8d2400687d9c5fb7701ec504d36179c8540d3b95#diff-1af98f4f9d8f628228b27c63a845c4a55ba73851fc1341feeb98d961bca75d4b

These toolchains aren't fully documented yet, but +Tom Rybka started a doc: https://github.com/trybka/scraps/blob/master/cc_test.md

--
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/6617dc6a-b3f6-44a1-8f7c-7b2e9e7a8d4fn%40googlegroups.com.

Filip Filmar

unread,
Aug 26, 2024, 1:19:33 PMAug 26
to Fabian Meumertzheim, Alexander Szakaly, Tom Rybka, bazel-discuss
Reply all
Reply to author
Forward
0 new messages