As discussed in #602440 since upgrading to sandbox-2.12 or 2.13 on an ARM qemu chroot, I can no longer emerge musl. QEMU-user does not support syscall 26 (ptrace). As a result, sandbox versions above 2.10 which use ptrace more heavily fail when running on (at least) musl's /usr/lib/libc.so. I'm not sure what makes that binary special, but all other packages in my world (~250 of them) emerged fine without hitting the same error. If I manually run "sandbox /usr/lib/libc.so" I get: qemu: Unsupported syscall: 26 * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/trace.c:_do_ptrace():75: failure (Function not implemented): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x00000000, 0x00000000): Function not implemented /proc/32500/cmdline: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c /usr/lib/libc.so Which causes portage to (rightly) halt. On sandbox-2.10, I might see something like: * Unable to trace static ELF: /usr/lib/libc.so: /usr/lib/libc.so musl libc (armhf) Version 1.1.18 Dynamic Program Loader Usage: /usr/lib/libc.so [options] [--] pathname [args] Reproducible: Always
This doesn't seem like a bug in sandbox, but rather missing functionality in qemu. I suggest disabling sandbox support in portage as a workaround.
I think that the problematic part in the musl ebuild might get changed soon. See bug 645626.
Now that sandbox-2.12 is stable, I've seen more of this type of failure. Latest was glibc, and I think I had trouble with glib as well. I agree this is a deficiency of qemu, but as ptrace is not likely to ever be implemented in qemu according to what I've read, I'm wondering how best to workaround. Is there a more conservative thing to do than just disable sandbox altogether?
@Mike Gilbert In my qemu chroot(s), I've rebuilt sandbox, but during configure I removed #define HAVE_PTRACE from config.h, thus cutting out the ptrace logic. I _think_ I still get any other benefits of sandbox (NB I don't even pretend to understand what the ptrace stuff does, but I still get things like directory write protection) On my real hardware, I still have the sandbox with full ptrace support, so it would catch anything my qemu chroot did not when I install the binaries? Is this a reasonable approach? Sorry to nag, but I'm just of the mind that some protection is better than none.
Hmm, maybe we should add 'ptrace' USE flag for this. Possibly package.use.force it for everyone, leaving unmasking and disabling as an alternative for people using qemu-user.
Actually, I am not sure what I was thinking when I grabbed the bug. Reassigning to sandbox maintainers.
*** This bug has been marked as a duplicate of bug 300679 ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=c4bf07615cd2e2ec25a16420d8ddee2efec6f8d2 commit c4bf07615cd2e2ec25a16420d8ddee2efec6f8d2 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-18 06:47:59 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-18 06:47:59 +0000 libsandbox: add SANDBOX_METHOD setting This allows people to disable use of ptrace if their configuration does not support it. This forces older sandbox behavior where we cannot protect against static or set*id programs. Bug: https://bugs.gentoo.org/648516 Bug: https://bugs.gentoo.org/771360 Signed-off-by: Mike Frysinger <vapier@gentoo.org> etc/sandbox.conf | 11 ++++++++++ libsandbox/libsandbox.c | 10 +++++++++ libsandbox/libsandbox.h | 1 + libsandbox/wrapper-funcs/__wrapper_exec.c | 4 ++++ libsbutil/Makefile.am | 1 + libsbutil/sb_method.c | 34 +++++++++++++++++++++++++++++++ libsbutil/sbutil.h | 11 ++++++++++ src/environ.c | 3 +++ 8 files changed, 75 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=d8b9a41d76de38cab079951cd494cdb491b55126 commit d8b9a41d76de38cab079951cd494cdb491b55126 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-31 23:50:01 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-31 23:50:01 +0000 libsandbox: do not use ptrace if it returns ENOSYS QEMU's linux-user does not implement ptrace for any architecture, and any attempt to call it fails with ENOSYS. Detect that scenario. Closes: https://bugs.gentoo.org/648516 Signed-off-by: Mike Frysinger <vapier@gentoo.org> libsandbox/trace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
