Re: 0.161 elfutils test are failing on Linux Arch

Re: 0.161 elfutils test are failing on Linux Arch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On Thu, Jan 15, 2015 at 12:06:51PM +0100, Mark Wielaard wrote:
[...]
> 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.

JFYI, we use the same approach in strace to make some of our tests work
properly on such systems:
http://sourceforge.net/p/strace/code/ci/master/tree/tests/set_ptracer_any.c

> 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?

A consumer OS in default configuration does not allow ptrace'ing of
firefox for security reasons.  If a user wants to ptrace processes other
than direct descendants, there is no other way besides lifting the ptrace
restrictions.

Unfortunately, there is a consumer culture of wrapping in sudo any command
that fails with EPERM, but that's another problem.


-- 
ldv

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

On Sat, 2015-01-17 at 17:04 +0300, Dmitry V. Levin wrote:
> On Thu, Jan 15, 2015 at 12:06:51PM +0100, Mark Wielaard wrote:
> > 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.
> 
> JFYI, we use the same approach in strace to make some of our tests work
> properly on such systems:
> http://sourceforge.net/p/strace/code/ci/master/tree/tests/set_ptracer_any.c

Thanks. It felt a bit weird/backwards to do it this way. But if others
also work around this brokenness this way it hopefully will be supported
for some time.

> > 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?
> 
> A consumer OS in default configuration does not allow ptrace'ing of
> firefox for security reasons.  If a user wants to ptrace processes other
> than direct descendants, there is no other way besides lifting the ptrace
> restrictions.
> 
> Unfortunately, there is a consumer culture of wrapping in sudo any command
> that fails with EPERM, but that's another problem.

Yeah. I don't know precisely what a "consumer OS" is. But crippling
things so the user cannot even inspect what their own processes do feels
broken. Especially if the only way to work around it is to run
everything with elevated privileges. It feels like someone decided that
having firefox do inter-process communication through ptrace with
something like xchat might be a bad idea (and it probably is). But then
"fixed" things by disallowing any inter-process communication.
Effectively making users just run everything as root. The correct
approach would be to either run such processes in different security
domains. Or removing the ptrace capability from processes that don't
need it, like firefox or xchat, and make sure they or their children
cannot regain that capability. But an approach that makes the
user/consumer not be able to introspect what their own processes are
doing is broken and will result in less security since users will then
run everything as root to regain the capability.

Thanks,

Mark

Re: 0.161 elfutils test are failing on Linux Arch

[Josh Stone]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

On 01/16/2015 08:02 AM, Mark Wielaard wrote:
> On Fri, 2015-01-16 at 06:12 -0800, Anatol Pomozov wrote:
>> On Thu, Jan 15, 2015 at 3:06 AM, Mark Wielaard <mjw@redhat.com> wrote:
>>> 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
> 
> OK. That would happen if the system doesn't create core dump files in
> the working directory. Those tests try to create a core dump and then
> inspect it. They SKIP the test if the core file isn't generated for some
> reason.

I also get this on Fedora 21 thanks to systemd-coredump.


>> I get "Operation not permitted", my understanding that in this case user
>> should use sudo.
> 
> Hmmm. That sounds pretty bad from a security perspective. So you
> basically have to have root to do any process introspection? That means
> eu-stack -p probably also only works when run with root privileges.

Security folks don't trust ptrace.  Fedora has the deny_ptrace selinux
bool too, but thankfully that's off by default.
(yay double negative... deny is off -> ptrace is allowed)

https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Fri, 2015-01-16 at 06:12 -0800, Anatol Pomozov wrote:
> On Thu, Jan 15, 2015 at 3:06 AM, Mark Wielaard <mjw@redhat.com> wrote:
> > 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

OK. That would happen if the system doesn't create core dump files in
the working directory. Those tests try to create a core dump and then
inspect it. They SKIP the test if the core file isn't generated for some
reason.

> > 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.

Thanks for testing. I pushed the patch to master.

> > 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.

Hmmm. That sounds pretty bad from a security perspective. So you
basically have to have root to do any process introspection? That means
eu-stack -p probably also only works when run with root privileges.

Cheers,

Mark

Re: 0.161 elfutils test are failing on Linux Arch

[Anatol Pomozov]

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

Hi

On Thu, Jan 15, 2015 at 3:06 AM, Mark Wielaard <mjw@redhat.com> 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 <mjw@redhat.com> 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.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3991 bytes --]

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

On Thu, 2015-01-15 at 12:06 +0100, Mark Wielaard wrote:
> I'll try to code something up and if you could test that, that would be
> awesome.

Could you try this patch?

Thanks,

Mark

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-tests-Make-deleted-and-vdsosyms-testcases-work-with-.patch --]
[-- Type: text/x-patch, Size: 2586 bytes --]

From 224e6776cfe6fc23a207cd05bf75b1e3548853a0 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mjw@redhat.com>
Date: Thu, 15 Jan 2015 13:39:06 +0100
Subject: [PATCH] tests: Make deleted and vdsosyms testcases work with
 "restricted ptrace".

Some systems might have "restricted ptrace" that doesn't allow process
inspection of arbitrary processes. Change the deleted testcase to
explicitly allow any other process to inspect it using the PR_SET_PTRACER
prctl set to PR_SET_PTRACER_ANY. Change the vdsosyms testcase to inspect
the process itself which should always be allowed.

Reported-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Mark Wielaard <mjw@redhat.com>
---
 tests/ChangeLog  | 5 +++++
 tests/deleted.c  | 6 ++++++
 tests/vdsosyms.c | 5 +++--
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tests/ChangeLog b/tests/ChangeLog
index 38126a9..4671390 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-15  Mark Wielaard  <mjw@redhat.com>
+
+	* deleted.c (main): Call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY).
+	* vdsosyms.c (main): Use getpid () instead of getppid ().
+
 2015-01-07  Mark Wielaard  <mjw@redhat.com>
 
 	* run-addrcfi.sh: Add test for ppc32 eh_frame_hdr address search.
diff --git a/tests/deleted.c b/tests/deleted.c
index 32a310b..d071bf7 100644
--- a/tests/deleted.c
+++ b/tests/deleted.c
@@ -23,6 +23,7 @@
 #include <stdio.h>
 #include <error.h>
 #include <errno.h>
+#include <sys/prctl.h>
 
 extern void libfunc (void);
 
@@ -42,6 +43,11 @@ main (int argc __attribute__ ((unused)), char **argv __attribute__ ((unused)))
       assert (!err);
       err = close (2);
       assert (!err);
+      /* Make sure eu-stack -p works on this process even with
+	 "restricted ptrace".  */
+#ifdef PR_SET_PTRACER_ANY
+      prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);
+#endif
       libfunc ();
       abort ();
     }
diff --git a/tests/vdsosyms.c b/tests/vdsosyms.c
index c1f8d89..4f12b9a 100644
--- a/tests/vdsosyms.c
+++ b/tests/vdsosyms.c
@@ -80,8 +80,9 @@ main (int argc __attribute__ ((unused)), char **argv __attribute__ ((unused)))
   if (dwfl == NULL)
     error (2, 0, "dwfl_begin: %s", dwfl_errmsg (-1));
 
-  /* Take our parent as "arbitrary" process to inspect.  */
-  pid_t pid = getppid();
+  /* Take ourself as "arbitrary" process to inspect.  This should work
+     even with "restricted ptrace".  */
+  pid_t pid = getpid();
 
   int result = dwfl_linux_proc_report (dwfl, pid);
   if (result < 0)
-- 
1.8.3.1

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

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 <mjw@redhat.com> 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

Re: 0.161 elfutils test are failing on Linux Arch

[Anatol Pomozov]

[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]

Hi Mark

On Wed, Jan 14, 2015 at 1:16 PM, Mark Wielaard <mjw@redhat.com> wrote:

> On Wed, 2015-01-14 at 11:51 -0800, Anatol Pomozov wrote:
> > > > [anatol(a)arch tests]$ cat run-deleted.sh.log
> > > > PID 22079 - process
> > > > TID 22079:
> > > >
> > >
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > > > dwfl_thread_getframes tid 22079: Operation not permitted
> > > >
> > >
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > > > Couldn't show any frames.
> > > >
> > > >
> > > > Is it a known issue with 0.161?
> > >
> > > Not a know issue.
> > >
> > > The first error message isn't very helpful. But the second might
> > > indicate some ptrace operation or reading /proc/pid/mem is not
> > > permitted. Both tests rely on being able to attach to and read from the
> > > process memory to get the ELF image (the first for the vdso, the second
> > > for the deleted.so).
> > >
> > > There have been selinux setting that prevented any such operation.
> Maybe
> > > Arch linux enables something like that?
> > >
> >
> > No, my kernel (3.18.2)  does not have SELinux enabled. Here is kernel
> > config file https://gist.github.com/anatol/d4da6afda94d479ca142
>
> 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






[anatol(a)arch tests]$ ./vdsosyms
module name: /usr/bin/bash
module name: /usr/lib/libnss_files-2.20.so
module name: /usr/lib/libc-2.20.so
module name: /usr/lib/libdl-2.20.so
module name: /usr/lib/libncursesw.so.5.9
module name: /usr/lib/libreadline.so.6.3
module name: /usr/lib/ld-2.20.so
module name: /usr/lib/locale/locale-archive
module name: /usr/lib/ld-2.20.so
module name: [vdso: 22670]
vdso syms: 11
0: '' 0 (0)
1: '' 418 (7fffd6171418)
2: 'clock_gettime' ac0 (7fffd6171ac0)
3: 'LINUX_2.6' 0 (0)
4: '__vdso_gettimeofday' da0 (7fffd6171da0)
5: '__vdso_getcpu' f50 (7fffd6171f50)
6: 'gettimeofday' da0 (7fffd6171da0)
7: 'time' f30 (7fffd6171f30)
8: 'getcpu' f50 (7fffd6171f50)
9: '__vdso_clock_gettime' ac0 (7fffd6171ac0)
10: '__vdso_time' f30 (7fffd6171f30)
[anatol(a)arch tests]$ echo $?
0


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?



> > How to run a single test?
> >
> > [anatol(a)arch tests]$ ./run-deleted.sh
> > ./run-deleted.sh: line 18: /backtrace-subr.sh: No such file or directory
> > ./run-deleted.sh: line 20: tempfiles: command not found
> > cp: cannot stat ‘/deleted’: No such file or directory
> > cp: cannot stat ‘/deleted-lib.so’: No such file or directory
> > ./run-deleted.sh: line 28: testrun: command not found
> > ./run-deleted.sh: line 31: tempfiles: command not found
> > ./run-deleted.sh: line 36: testrun: command not found
> > kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ...
> or
> > kill -l [sigspec]
> > ./run-deleted.sh: line 40: check_native_unsupported: command not found
> >
> > does not look right. I would like like to run/gdb the command that fails.
>
> It is mostly a simple shell testcase. But with some convenience macros.
> In your build dir create a directory. Copy deleted and deleted-lib.so
> from the build tests dir into this temp dir. change the pwd to this temp
> dir. Run the deleted program and note its pid. rm deleted-lib.so. Then
> run the src/stack program from your build dir on the pid. And that under
> gdb if you want to debug using the LD_LIBRARY_PATH set to the just build
> libraries.
>
> $ mkdir temp
> $ cd temp
> $ cp ../tests/deleted ../tests/deleted-lib.so .
> $ ./deleted
> 2285
> $ rm deleted-lib.so
> $ cd ..
> $ LD_LIBRARY_PATH=backends:libelf:libdw gdb --args src/stack -v -p 2285
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /opt/local/build/elfutils-obj/src/stack...done.
> (gdb) r
> Starting program: /opt/local/build/elfutils-obj/src/stack -v -p 2285
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> PID 2285 - process
> TID 2285:
> #0  0x00007ff551b254c0     __nanosleep - /usr/lib64/libc-2.17.so
>     ../sysdeps/unix/syscall-template.S:81
> #1  0x00007ff551b25374 - 1 __sleep - /usr/lib64/libc-2.17.so
>     ../sysdeps/unix/sysv/linux/sleep.c:137
> #2  0x00007ff551e296d6 - 1 libfunc -
> /opt/local/build/elfutils-obj/temp/deleted-lib.so (deleted)
> #3  0x0000000000400938 - 1 main -
> /opt/local/build/elfutils-obj/temp/deleted
>     /home/mark/src/elfutils/tests/deleted.c:45
> #4  0x00007ff551a89af5 - 1 __libc_start_main - /usr/lib64/libc-2.17.so
>     /usr/src/debug/glibc-2.17-c758a686/csu/libc-start.c:274
> #5  0x0000000000400799 - 1 _start -
> /opt/local/build/elfutils-obj/temp/deleted
> [Inferior 1 (process 2382) exited normally]
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 8253 bytes --]

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]

On Wed, 2015-01-14 at 11:51 -0800, Anatol Pomozov wrote:
> > > [anatol(a)arch tests]$ cat run-deleted.sh.log
> > > PID 22079 - process
> > > TID 22079:
> > >
> > /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > > dwfl_thread_getframes tid 22079: Operation not permitted
> > >
> > /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > > Couldn't show any frames.
> > >
> > >
> > > Is it a known issue with 0.161?
> >
> > Not a know issue.
> >
> > The first error message isn't very helpful. But the second might
> > indicate some ptrace operation or reading /proc/pid/mem is not
> > permitted. Both tests rely on being able to attach to and read from the
> > process memory to get the ELF image (the first for the vdso, the second
> > for the deleted.so).
> >
> > There have been selinux setting that prevented any such operation. Maybe
> > Arch linux enables something like that?
> >
> 
> No, my kernel (3.18.2)  does not have SELinux enabled. Here is kernel
> config file https://gist.github.com/anatol/d4da6afda94d479ca142

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.

> How to run a single test?
> 
> [anatol(a)arch tests]$ ./run-deleted.sh
> ./run-deleted.sh: line 18: /backtrace-subr.sh: No such file or directory
> ./run-deleted.sh: line 20: tempfiles: command not found
> cp: cannot stat ‘/deleted’: No such file or directory
> cp: cannot stat ‘/deleted-lib.so’: No such file or directory
> ./run-deleted.sh: line 28: testrun: command not found
> ./run-deleted.sh: line 31: tempfiles: command not found
> ./run-deleted.sh: line 36: testrun: command not found
> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or
> kill -l [sigspec]
> ./run-deleted.sh: line 40: check_native_unsupported: command not found
> 
> does not look right. I would like like to run/gdb the command that fails.

It is mostly a simple shell testcase. But with some convenience macros.
In your build dir create a directory. Copy deleted and deleted-lib.so
from the build tests dir into this temp dir. change the pwd to this temp
dir. Run the deleted program and note its pid. rm deleted-lib.so. Then
run the src/stack program from your build dir on the pid. And that under
gdb if you want to debug using the LD_LIBRARY_PATH set to the just build
libraries.

$ mkdir temp
$ cd temp
$ cp ../tests/deleted ../tests/deleted-lib.so .
$ ./deleted
2285
$ rm deleted-lib.so
$ cd ..
$ LD_LIBRARY_PATH=backends:libelf:libdw gdb --args src/stack -v -p 2285
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/local/build/elfutils-obj/src/stack...done.
(gdb) r
Starting program: /opt/local/build/elfutils-obj/src/stack -v -p 2285
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
PID 2285 - process
TID 2285:
#0  0x00007ff551b254c0     __nanosleep - /usr/lib64/libc-2.17.so
    ../sysdeps/unix/syscall-template.S:81
#1  0x00007ff551b25374 - 1 __sleep - /usr/lib64/libc-2.17.so
    ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x00007ff551e296d6 - 1 libfunc - /opt/local/build/elfutils-obj/temp/deleted-lib.so (deleted)
#3  0x0000000000400938 - 1 main - /opt/local/build/elfutils-obj/temp/deleted
    /home/mark/src/elfutils/tests/deleted.c:45
#4  0x00007ff551a89af5 - 1 __libc_start_main - /usr/lib64/libc-2.17.so
    /usr/src/debug/glibc-2.17-c758a686/csu/libc-start.c:274
#5  0x0000000000400799 - 1 _start - /opt/local/build/elfutils-obj/temp/deleted
[Inferior 1 (process 2382) exited normally]

Re: 0.161 elfutils test are failing on Linux Arch

[Anatol Pomozov]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

Hi

On Wed, Jan 14, 2015 at 11:41 AM, Mark Wielaard <mjw@redhat.com> wrote:

> On Wed, 2015-01-14 at 11:19 -0800, Anatol Pomozov wrote:
> > I am trying to build elfutils 0.161 on Linux Arch and 2 tests are
> failing.
> > Building 0.160 on the same machine is fine.
> > [...]
> > FAIL: vdsosyms
> > FAIL: run-deleted.sh
> >
> >
> > [anatol(a)arch tests]$ cat vdsosyms.log
> > module name: /usr/bin/bash
> > module name: /usr/lib/libc-2.20.so
> > module name: /usr/lib/libdl-2.20.so
> > module name: /usr/lib/libncursesw.so.5.9
> > module name: /usr/lib/libreadline.so.6.3
> > module name: /usr/lib/ld-2.20.so
> > module name: [vdso: 22118]
> > vdso syms: -1
> > ./vdsosyms: dwfl_module_getsymtab: Callback returned failure
> >
> >
> > [anatol(a)arch tests]$ cat run-deleted.sh.log
> > PID 22079 - process
> > TID 22079:
> >
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > dwfl_thread_getframes tid 22079: Operation not permitted
> >
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> > Couldn't show any frames.
> >
> >
> > Is it a known issue with 0.161?
>
> Not a know issue.
>
> The first error message isn't very helpful. But the second might
> indicate some ptrace operation or reading /proc/pid/mem is not
> permitted. Both tests rely on being able to attach to and read from the
> process memory to get the ELF image (the first for the vdso, the second
> for the deleted.so).
>
> There have been selinux setting that prevented any such operation. Maybe
> Arch linux enables something like that?
>

No, my kernel (3.18.2)  does not have SELinux enabled. Here is kernel
config file https://gist.github.com/anatol/d4da6afda94d479ca142

How to run a single test?

[anatol(a)arch tests]$ ./run-deleted.sh
./run-deleted.sh: line 18: /backtrace-subr.sh: No such file or directory
./run-deleted.sh: line 20: tempfiles: command not found
cp: cannot stat ‘/deleted’: No such file or directory
cp: cannot stat ‘/deleted-lib.so’: No such file or directory
./run-deleted.sh: line 28: testrun: command not found
./run-deleted.sh: line 31: tempfiles: command not found
./run-deleted.sh: line 36: testrun: command not found
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or
kill -l [sigspec]
./run-deleted.sh: line 40: check_native_unsupported: command not found

does not look right. I would like like to run/gdb the command that fails.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3398 bytes --]

Re: 0.161 elfutils test are failing on Linux Arch

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On Wed, 2015-01-14 at 11:19 -0800, Anatol Pomozov wrote:
> I am trying to build elfutils 0.161 on Linux Arch and 2 tests are failing.
> Building 0.160 on the same machine is fine.
> [...]
> FAIL: vdsosyms
> FAIL: run-deleted.sh
> 
> 
> [anatol(a)arch tests]$ cat vdsosyms.log
> module name: /usr/bin/bash
> module name: /usr/lib/libc-2.20.so
> module name: /usr/lib/libdl-2.20.so
> module name: /usr/lib/libncursesw.so.5.9
> module name: /usr/lib/libreadline.so.6.3
> module name: /usr/lib/ld-2.20.so
> module name: [vdso: 22118]
> vdso syms: -1
> ./vdsosyms: dwfl_module_getsymtab: Callback returned failure
> 
> 
> [anatol(a)arch tests]$ cat run-deleted.sh.log
> PID 22079 - process
> TID 22079:
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> dwfl_thread_getframes tid 22079: Operation not permitted
> /home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
> Couldn't show any frames.
> 
> 
> Is it a known issue with 0.161?

Not a know issue.

The first error message isn't very helpful. But the second might
indicate some ptrace operation or reading /proc/pid/mem is not
permitted. Both tests rely on being able to attach to and read from the
process memory to get the ELF image (the first for the vdso, the second
for the deleted.so).

There have been selinux setting that prevented any such operation. Maybe
Arch linux enables something like that?

0.161 elfutils test are failing on Linux Arch

[Anatol Pomozov]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Hi

I am trying to build elfutils 0.161 on Linux Arch and 2 tests are failing.
Building 0.160 on the same machine is fine.

============================================================================
Testsuite summary for elfutils 0.161
============================================================================
# TOTAL: 129
# PASS:  125
# SKIP:  2
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to https://bugzilla.redhat.com/
============================================================================

FAIL: vdsosyms
FAIL: run-deleted.sh


[anatol(a)arch tests]$ cat vdsosyms.log
module name: /usr/bin/bash
module name: /usr/lib/libc-2.20.so
module name: /usr/lib/libdl-2.20.so
module name: /usr/lib/libncursesw.so.5.9
module name: /usr/lib/libreadline.so.6.3
module name: /usr/lib/ld-2.20.so
module name: [vdso: 22118]
vdso syms: -1
./vdsosyms: dwfl_module_getsymtab: Callback returned failure


[anatol(a)arch tests]$ cat run-deleted.sh.log
PID 22079 - process
TID 22079:
/home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
dwfl_thread_getframes tid 22079: Operation not permitted
/home/anatol/sources/core-arch/elfutils/trunk/src/elfutils-0.161/src/stack:
Couldn't show any frames.


Is it a known issue with 0.161?

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2032 bytes --]