Hi Anatol, On Wed, 2015-01-14 at 13:30 -0800, Anatol Pomozov wrote: > On Wed, Jan 14, 2015 at 1:16 PM, Mark Wielaard wrote: > > You do seem to have yama and alternate selinux security module enabled > > it seems. Make sure it doesn't deny ptrace/proc/mem. > > Probably /proc/sys/kernel/yama/ptrace_scope should be set to zero. > > > Thanks for your pointer. My computer has YAMA indeed. The default > ptrace_scope value is YAMA_SCOPE_RELATIONAL (1) and it is what my computer > has. > > I temporary disabled YAMA with > # sudo sysctl kernel.yama.ptrace_scope=0 > > and now tests are passed: > > ============================================================================ > Testsuite summary for elfutils 0.161 > ============================================================================ > # TOTAL: 129 > # PASS: 127 > # SKIP: 2 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 Awesome! BTW. Which architecture and what are the two SKIPPED tests? > So what I (as a packager) suppose to do here? I doubt that YAMA will be > disabled in the default kernel. Should I just ignore these test failures? > Or maybe "make check" should ignore these 2 tests if YAMA enabled? Lets see if we can change the tests first to allow proper introspection in this case (which hopefully also helps in the selinux case). I think for the vdsosyms test we can just fork a child process instead to look at the vdso instead of picking a random process. Currently it does: /* Take our parent as "arbitrary" process to inspect. */ pid_t pid = getppid(); And for the deleted test we can probably first call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0) to allow eu-stack -p to get at the memory image of the deleted-lib.so. I'll try to code something up and if you could test that, that would be awesome. But... This is really workarounds for the testcases. Then we know the functionality works as intended. Except when a real user uses the dwfl attach library calls or eu-stack binary... So we probably need to figure out how to really fix this. How do other tools and libraries work? What if a user wants to see why firefox is wonky and does a strace -p $(pidof firefox) or gstack $(pidof firefox). Are those tools also broken by default on Arch? Or do they use some other trick to work properly? Thanks, Mark