with ptrace_scope set to: #cat /proc/sys/kernel/yama/ptrace_scope 2 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace with PTRACE_ATTACH, or through children calling PTRACE_TRACEME. and FEATURES="userfetch userpriv usersandbox" i get errors like this while compiling gcc: checking whether the target supports thread-local storage... * /tmp/tmerge/portage/sys-apps/sandbox-2.10-r4/work/sandbox-2.10/libsandbox/trace.c:_do_ptrace():74: failure (Operation not permitted): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted this happens a lot of times: # grep -i ptrace emerge.output|wc -l 56 and although the compile doesn't break i get errors like this when using the compiled gcc( libs) to start for example libtreoffice-bin: /usr/lib64/libreoffice/program/soffice.bin: relocation error: /usr/lib64/libreoffice/program/libmergedlo.so: symbol _ZSt11__once_call, version GLIBCXX_3.4.11 not defined in file libstdc++.so.6 with link time reference compiling gcc with ptrace_scope set to "0" or "1" solves the relocation error for libreoffice-bin i think the user should at least get a warining when compiling gcc with FEATURES="userpriv usersandbox" and ptrace_scope == 2 Reproducible: Always
as the build doesn't break with ptrace_scope >= 2 and FEATURES="userfetch userpriv usersandbox", i think this bug should be assigned to the gcc and portage maintainers
ping
(In reply to Herbert Wantesh from comment #1) > as the build doesn't break with ptrace_scope >= 2 and FEATURES="userfetch > userpriv usersandbox", i think this bug should be assigned to the gcc and > portage maintainers Your kernel does not allow ptrace(). portage's sandbox uses it to implement sandbox. You either need to whitelist ptrace() or disable sandbox. I'm not familiar with yama and don't know how to do it. FEATURES="-sandbox -usersandbox" is a workaround for you, right? What do you expect gcc maintainers to do here?
(In reply to Sergei Trofimovich from comment #3) > (In reply to Herbert Wantesh from comment #1) > > as the build doesn't break with ptrace_scope >= 2 and FEATURES="userfetch > > userpriv usersandbox", i think this bug should be assigned to the gcc and > > portage maintainers > > Your kernel does not allow ptrace(). portage's sandbox uses it to implement > sandbox. You either need to whitelist ptrace() or disable sandbox. I'm not > familiar with yama and don't know how to do it. > > FEATURES="-sandbox -usersandbox" is a workaround for you, right? > > What do you expect gcc maintainers to do here? as i mentioned before: i think the user should at least get a warining when compiling gcc with FEATURES="userpriv usersandbox" and ptrace_scope == 2 compiling gcc without an error and creating a handicapped gcc is not acceptable
It does not looks like gcc-specific failure. Any ebuild that happens to link and run static binaries would have a chance to fail in similarly obscure ways. Perhaps better handling would be to detect EPERMs from ptrace() in sandbox and declare defeat in attempts to trace the binary. Extending trace_possible() would be one of solutions: https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/trace.c#n564
so, can someone add "Mike Frysinger" to this bug report. and maybe the portage maintainer "Zac Medico".(In reply to Sergei Trofimovich from comment #5) > It does not looks like gcc-specific failure. Any ebuild that happens to link > and run static binaries would have a chance to fail in similarly obscure > ways. > > Perhaps better handling would be to detect EPERMs from ptrace() in sandbox > and declare defeat in attempts to trace the binary. Extending > trace_possible() would be one of solutions: > > https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/trace.c#n564 so, can someone add "Mike Frysinger" to this bug report. and maybe the portage maintainer "Zac Medico". maybe they can the way how this should be handled
(In reply to Sergei Trofimovich (RETIRED) from comment #3) > What do you expect gcc maintainers to do here? ... so we reassign to sandbox? (In reply to Sergei Trofimovich (RETIRED) from comment #5) > Perhaps better handling would be to detect EPERMs from ptrace() in sandbox > and declare defeat in attempts to trace the binary. Extending > trace_possible() would be one of solutions: > > https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/trace.c#n564 Indeed another reason to keep it open.
we discussed this a bit more in detail in the newer issue 771360 *** This bug has been marked as a duplicate of bug 771360 ***
