Build Fails when compiling on musl-libc system about nsjail HOT 6 CLOSED

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

from nsjail.

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.

from nsjail.

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

from nsjail.

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.

from nsjail.

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.

from nsjail.

Applied in f388cad

Thanks for testing!

from nsjail.