Bug 706020

Summary:	sys-apps/sandbox: wrappers are broken when cross compiled using different libc
Product:	Portage Development	Reporter:	Andrew Aladjev <aladjev.andrew>
Component:	Sandbox	Assignee:	Sandbox Maintainers <sandbox>
Status:	RESOLVED WONTFIX
Severity:	enhancement	CC:	aladjev.andrew, slyfox
Priority:	Lowest
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Andrew Aladjev 2020-01-21 18:20:01 UTC

Hello. I am doing cross compiling of portage using "x86_64-pc-linux-musl" toolchain. Sandbox was cross compiled using same toolchain.

"LD_LIBRARY_PATH='/usr/x86_64-pc-linux-musl/usr/lib' ldd -v /usr/x86_64-pc-linux-musl/usr/lib/libsandbox.so" provides:

linux-vdso.so.1 (0x00007ffc5c5cd000)
libc.so => /usr/x86_64-pc-linux-musl/usr/lib/libc.so (0x00007f3b52c96000)

"libc.so" is musl.

"FEATURES='-usersandbox' x86_64-pc-linux-musl-emerge -v1 portage" works perfect.

"x86_64-pc-linux-musl-emerge -v1 portage" returned segfault. Please see the following build.log.  https://gist.github.com/andrew-aladev/6dd1efd9d6092acfb4ac94d48a6ebdea

x86_64-pc-linux-musl-gcc -O2 -pipe -fPIC -I/usr/x86_64-pc-linux-musl/usr/include/python3.6m -c src/portage_util_libc.c -o /usr/x86_64-pc-linux-musl/tmp/portage/sys-apps/portage-2.3.79/work/portage-2.3.79-python3_6/temp.linux-x86_64-3.6/src/portage_util_libc.o -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
error: command 'x86_64-pc-linux-musl-gcc' terminated by signal 11

Than I am analyzing coredump:
gdb /usr/x86_64-pc-linux-gnu/x86_64-pc-linux-musl/gcc-bin/9.2.0/x86_64-pc-linux-musl-gcc /usr/x86_64-pc-linux-musl/tmp/portage/sys-apps/portage-2.3.79/work/portage-2.3.79/core --batch --quiet -ex "thread apply all bt full" -ex "quit"

Please see the following log https://gist.github.com/andrew-aladev/04fcb14af7b5c9ed4a363a3e95a8d9d7.

We can see that some glibc call (/lib64/ld-linux-x86-64.so.2, it is glibc) was redirected by sandbox to musl "__dlsym" (ldso/dynlink.c:2235, it is musl) and musl provided segfault.

I don't know whether sandbox can redirect calls between different libcs, so I am not sure whether it is bug or not. I want just to provide you with information.

Thank you.

Reproducible: Always

Comment 1 Andrew Aladjev 2020-01-21 21:18:17 UTC

For now it is easy to workaround this bug:

```
"${TARGET}-emerge" -v1 sys-apps/sandbox
rm "/usr/${TARGET}/usr/lib/libsandbox.so"

"${TARGET}-emerge" -v1 sys-apps/portage

build "${TARGET}-emerge" -v1 sys-apps/sandbox
```

Cross emerge will load native sandbox (even with LD_LIBRARY_PATH="/usr/${TARGET}/...") instead of cross compiled one.

Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev

2020-01-21 22:11:18 UTC

> Cross emerge will load native sandbox (even with LD_LIBRARY_PATH="/usr/${TARGET}/...") instead of cross compiled one.

That's expected. You are normally running only host's binaries when cross-compiling.

If you are running both host's and target's binaries during cross-compilation you have to disable sandbox (it's arguably a bug to even attempt that). There is no way to safely preload same library into both.

Comment 3 Andrew Aladjev 2020-01-22 08:02:11 UTC

Ok, thank you. I will note that it is not a bug.

Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev

2020-01-22 19:46:47 UTC

(In reply to Andrew Aladjev from comment #3)
> Ok, thank you. I will note that it is not a bug.

I still don't think sandbox can do much here.

If you'd like to fix a package or specific class of packages to prevent from executing target binaries on a host I suggest attaching example build log and direct the bug to specific maintainers.