strace is a pretty common debug tool for users when things go wrong and it's not clear why. they'll often break out something like `strace -f -o $T/log ...` to get the full process tree. unfortunately this breaks sandbox's ability to ptrace static children. the error message we emit is confusing for them. for example: $ echo 'main(){return 3;}' | gcc -x c - -o a.out -static $ sandbox $ ./a.out; echo $? 3 $ strace ./a.out +++ exited with 3 +++ $ strace -f -o log ./a.out strace -f -o log ./a.out * /var/tmp/portage/sys-apps/sandbox-2.11-r4/work/sandbox-2.11/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted /usr/lib64/libsandbox.so(+0xa935)[0x7f6dbadd3935] /usr/lib64/libsandbox.so(+0xaa15)[0x7f6dbadd3a15] /usr/lib64/libsandbox.so(+0x5dee)[0x7f6dbadcedee] /usr/lib64/libsandbox.so(+0x5b18)[0x7f6dbadceb18] /usr/lib64/libsandbox.so(+0x955f)[0x7f6dbadd255f] /usr/lib64/libsandbox.so(execv+0x50)[0x7f6dbadd1cb0] strace[0x42b8ca] strace[0x42a3ee] strace[0x4280af] /lib64/libc.so.6(__libc_start_main+0xee)[0x7f6dba82da8e] /proc/178078/cmdline: strace -f -o log ./a.out i'm not sure we've hit any scenarios in the years since ptrace has been deployed where PTRACE_TRACEME would fail with EPERM ... the only way that would happen is if the process is already being traced, or the kernel LSMs have restricted things in general (e.g. /proc/sys/kernel/yama/ptrace_scope is set to 2 or 3). we already whine when we're unable to ptrace a process on an unsupported system. we should special case PTRACE_TRACEME EPERM failures to do the same: whine but otherwise don't block/abort execution.
Agreed. A minor complication is that we detect failure of PTRACE_TRACEME in the running child when parent is about to track it's state in trace_loop(). I tried to shut down child and run execve() handler in parent of trace_main() but failed. Running handler in child is a bit more successful. Will spend a bit more time tomorrow and attach what I've got.
*** Bug 729950 has been marked as a duplicate of this bug. ***
Since I had the same issue with podman as mentioned in bug #729950 (only with gobject-introspection as the triggering package), I just wanted to mention that an alternative workaround to disabling the portage sandbox is to just pass --cap-add=CAP_SYS_PTRACE to podman-run(1) or podman-build(1), which also works in rootless mode.
