Hi On Thu, Jan 15, 2015 at 3:06 AM, Mark Wielaard <[email protected]> wrote:
> 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 <[email protected]> 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? > I have x86_64 and the skipped tests are SKIP: run-backtrace-native-core.sh SKIP: run-backtrace-native-core-biarch.sh > 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. > Thanks. The patch works great. All tests are passed now. > > 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? > I get "Operation not permitted", my understanding that in this case user should use sudo.
