Summary: | sys-devel/gcc-6.4.0 relocation errors when using a gcc that was compiled with FEATURES="userpriv usersandbox" and ptrace_scope >= 2 | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Herbert Wantesh <rauchwolke> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alexander, arthur, jah, sam, toolchain, tsmksubc, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=693582 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Herbert Wantesh
2017-12-11 15:51:59 UTC
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 *** |