google/nsjail

Build Fails when compiling on musl-libc system

Closed this issue · 6 comments

jvvv commented

Building nsjail on Alpine Linux, the following build failure occurs:

g++ -Os -fstack-clash-protection -Wformat -Werror=format-security -D_GLIBCXX_ASSERTIONS=1 -fno-plt  -O2 -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fPIE -Wformat -Wformat-security -Wno-format-nonliteral -Wall -Wextra -Werror -Ikafel/include -DPROTOBUF_USE_DLLS -DNOMINMAX -std=c++17 -fno-exceptions -Wno-unused -Wno-unused-parameter -I/usr/include/libnl3 cgroup.cc -o cgroup.o
g++ -Os -fstack-clash-protection -Wformat -Werror=format-security -D_GLIBCXX_ASSERTIONS=1 -fno-plt  -O2 -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fPIE -Wformat -Wformat-security -Wno-format-nonliteral -Wall -Wextra -Werror -Ikafel/include -DPROTOBUF_USE_DLLS -DNOMINMAX -std=c++17 -fno-exceptions -Wno-unused -Wno-unused-parameter -I/usr/include/libnl3 cgroup2.cc -o cgroup2.o
g++ -Os -fstack-clash-protection -Wformat -Werror=format-security -D_GLIBCXX_ASSERTIONS=1 -fno-plt  -O2 -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fPIE -Wformat -Wformat-security -Wno-format-nonliteral -Wall -Wextra -Werror -Ikafel/include -DPROTOBUF_USE_DLLS -DNOMINMAX -std=c++17 -fno-exceptions -Wno-unused -Wno-unused-parameter -I/usr/include/libnl3 cmdline.cc -o cmdline.o
protoc --cpp_out=. config.proto
protoc --cpp_out=. config.proto
cmdline.cc: In function 'uint64_t cmdline::parseRLimit(int, const char*, long unsigned int)':
cmdline.cc:285:24: error: 'RLIM64_INFINITY' was not declared in this scope; did you mean 'RLIM_INFINITY'?
  285 |                 return RLIM64_INFINITY;
      |                        ^~~~~~~~~~~~~~~
      |                        RLIM_INFINITY
cmdline.cc:287:25: error: aggregate 'cmdline::parseRLimit(int, const char*, long unsigned int)::rlimit64 cur' has incomplete type and cannot be defined
  287 |         struct rlimit64 cur;
      |                         ^~~
cmdline.cc:288:13: error: 'getrlimit64' was not declared in this scope; did you mean 'getrlimit'?
  288 |         if (getrlimit64(res, &cur) == -1) {
      |             ^~~~~~~~~~~
      |             getrlimit
make: *** [Makefile:60: cmdline.o] Error 1
make: *** Waiting for unfinished jobs....

The following musl-libc commits describe current and impending changes to musl:
https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448
https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a

For Alpine Linux, we are currently using the following patch to successfully build nsjail:
https://gitlab.alpinelinux.org/alpine/aports/-/blob/e0632e9c7ed71/testing/nsjail/rlimit64.patch

Technically, adding -D_LARGEFILE64_SOURCE would work for now, but will break again soon with the next musl release cycle. So a more long term change is preferred.

jvvv commented

So far, I have tested building with the above patch applied on most recent releases of Arch, Debian, Fedora, openSUSE, and Ubuntu, all glibc based distrobutions. Builds on each ran without warning or error. Resultant binary worked correctly, though not extensively tested; merely ran some commands in a fully (except network) isolated chroot like container.

Isn't it possible to use RLIM64_INFINITY and struct rlimit64 with musl?

These are defined in linux headers, maybe including <linux/resource.h> will help here?

Nothing prevents running 64-bit processes from 32-bit processes eg. under x86. If we used regular RLIM_INFINITY and struct rlimit64 then I'm worried the resources will be limited to 32-bit values for 64-bit processes.

Using syscall(__NR_prlimit64) instead of setrlimit64/getrlimit64 would help, but we still need those 64-bit structs/consts.

PS: I attached a patch using prlimit64, would it be possible to test it on musl-based systems?

prlimit64.patch.txt

jvvv commented

I have tested prlimit64.patch.txt; it still leaves occurences of rlimit64 and RLIM64_INFINITY, so compiling fails here. I tried your suggestion about including linux/resource.h, but failed due to redefinitions of several types.

I've spent some time this morning looking over both musl-libc and glibc source code. While I can't say that I didn't miss something, it looks to me that glibc typedefs or defines rlim64_t to rlim_t when FILE_OFFSET_BITS == 64 (similar handling of RLIM64_INFINITY also); for musl-libc, rlim_t is unsigned long long and the underlying code for getrlimit/setrlimit/prlimit uses the prlimit64 syscall. It is possible that I have missed some details in the code for glibc, so I will spend some more time later looking at it from that angle. I will try to get back about that in next day or so, time permitting.

I attach another patch. Maybe this?
rlim02.patch.txt

jvvv commented

The rlim02.patch.txt works well here. Compiles cleanly and no runtime errors noticed so far. I was hoping to find a way to do it without any preprocessor ifdef's, but your approach seems straight forward and to the point.

Applied in f388cad

Thanks for testing!