Running ./ltrace.main/system_calls.exp ... Running ./ltrace.minor/attach-process.exp ... FAIL: test case execution failed exec env LD_LIBRARY_PATH=/var/tmp/portage/dev-util/ltrace-0.7.3_p4-r1/work/ltrace-0.7.3/testsuite/ltrace.minor /var/tmp/portage/dev-util/ltrace-0.7.3_p4-r1/work/ltrace-0.7.3/testsuite/../ltrace -o /var/tmp/portage/dev-util/ltrace-0.7.3_p4-r1/temp/lt-DF8thWnn2c.ltrace -S -p 1117Cannot attach to pid 1117: Operation not permitted while executing exec env LD_LIBRARY_PATH=/var/tmp/portage/dev-util/ltrace-0.7.3_p4-r1/work/ltrace-0.7.3/testsuite/ltrace.minor /var/tmp/portage/dev-util/ltrace-0.7.3_... ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-test-20200620-211522 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10.1.0 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python2.7 (fallback) timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Sun 21 Jun 2020 08:05:29 PM UTC emerge -qpvO dev-util/ltrace [ebuild N ] dev-util/ltrace-0.7.3_p4-r1 USE="test -debug (-selinux) -unwind"
Created attachment 645562 [details] emerge-info.txt
Created attachment 645564 [details] dev-util:ltrace-0.7.3_p4-r1:20200621-202322.log
Created attachment 645566 [details] emerge-history.txt
Created attachment 645568 [details] environment
Created attachment 645570 [details] etc.portage.tbz2
Created attachment 645572 [details] logs.tbz2
Created attachment 645574 [details] temp.tbz2
FWIW there's bug 688526 too but this looks different at a first glance.
Looks similar. Is it deterministically failing if you try again?
(In reply to Sergei Trofimovich from comment #9) > Looks similar. Is it deterministically failing if you try again? at *this* image - yes (but I do currently have only 1 test image running)
I think I've reproduced this. Toralf: What have you got in /proc/sys/kernel/yama/ptrace_scope ?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea8a4b3bcf6a0a57f7cdb8e4d37ff62d099cb6a4 commit ea8a4b3bcf6a0a57f7cdb8e4d37ff62d099cb6a4 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2021-07-13 10:57:54 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2021-07-13 11:20:54 +0000 dev-util/ltrace: skip the attach-process test On modern kernels with the Yama security module enabled the default ptrace behaviour is that a process must have a predefined relationship with the inferior it wants to call ``PTRACE_ATTACH`` on, with two additional modes restricting process tracing even more; for details see [1]. As a result, unless Yama is explicitly reset to classic ptrace permissions the ltrace attach-process test fails due to insufficient permissions - regardless of the sandbox, or even when the test suite is run manually with no involvement of a Gentoo package manager. We could in principle modify the test in question to be compatible with restricted-ptrace mode, however it would still fail on systems with Yama in admin-attach and no-attach mode. Between that and requiring the user to reconfigure Yama prior to running this test being IMHO a Bad Idea, just don't bother with this test at all. [1] https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html Closes: https://bugs.gentoo.org/729046 Signed-off-by: Marek Szuba <marecki@gentoo.org> dev-util/ltrace/ltrace-0.7.3.6.1.ebuild | 4 ++++ dev-util/ltrace/ltrace-0.7.3_p4-r1.ebuild | 4 ++++ 2 files changed, 8 insertions(+)
(In reply to Marek Szuba from comment #11) > Toralf: What have you got in /proc/sys/kernel/yama/ptrace_scope ? There's no file at the build host - and the image is chanined with bubblewrap
