Description of problem:
I'm reporting this as a chrpath bug, because it APPEARS to be doing _something_ wrong, and the information it displays/modifies conflicts with every other tool I've used when investigating this issue.

When libraries have been modified by patchelf (for instance, to set a larger RUNPATH than was originally present, or to add one where none previously existed at all), subsequently using chrpath on those libraries produces incorrect results, and may even corrupt the symbols if chrpath is allowed to attempt modification of the library's RUNPATH.


Version-Release number of selected component (if applicable):
chrpath-0.16-15.fc34.x86_64

How reproducible:
I believe always? (Under specific circumstances.)

Steps to Reproduce:

As a minimum verifiable case, take the following C source file:

library.c
=========
#include <stdio.h>

void test_lib(void) {
	printf("%s\n", "Hello, shared library");
}

We can compile this into a shared library using gcc. In fact, let's do it twice, just so we have a way of testing the RUNPATH:

$ gcc --shared -fPIC -o library2.so library.c
$ gcc --shared -fPIC -L. -lrary2 -o library.so library.c

What we now have are two libraries, one of which is linked with the other but cannot find it:

$ ldd library.so
	linux-vdso.so.1 (0x00007ffeee5bd000)
	library2.so => not found
	libc.so.6 => /lib64/libc.so.6 (0x00007f6fa7912000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6fa7b2e000)

We can fix that using patchelf:

$ patchelf --set-rpath '$ORIGIN' library.so

library.so can now find library2.so:

$ ldd library.so
	linux-vdso.so.1 (0x00007ffc5a108000)
	library2.so => /var/tmp/rpath_tests/./library2.so (0x00007ffb61e9b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ffb61c86000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffb61ea8000)

$ readelf -d library.so |grep PATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]

chrpath, however, doesn't correctly read this RUNPATH from the modified library.so:

$ chrpath -l library.so
library.so: RUNPATH=nit_array_entry

And if I try to use chrpath to _change_ the RUNPATH, **REALLY** bad things happen:

$ chrpath -r '/var/tmp' library.so
library.so: RUNPATH=nit_array_entry
library.so: new RUNPATH: /var/tmp

$ readelf -d library.so |grep PATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]

Huh?? Where did our /var/tmp go?

$ nm library.so
0000000000004028 b completed.0
                 w __cxa_finalize.5
0000000000001050 t deregister_tm_clones
00000000000010c0 t __do_global_dtors_aux
0000000000003e00 d __do_global_dtors_aux_fini_array_entry
0000000000003e08 d __dso_handle
0000000000003e10 d _DYNAMIC
0000000000001120 t _fini
0000000000001100 t frame_dummy
0000000000003df8 d __frame_dummy_i/var/tmp
0000000000002098 r __FRAME_END__
0000000000004000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000002018 r __GNU_EH_FRAME_HDR
0000000000001000 t _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U puts.5
0000000000001080 t register_tm_clones
0000000000001109 T test_lib
0000000000004028 d __TMC_END__

chrpath has stuck it somewhere in the middle of a completely different symbol! It hasn't modified the RUNPATH at all — but if you ask it, it thinks it's doing everything right:

$ chrpath -l library.so
library.so: RUNPATH=/var/tmp

That seems bad, so let's use chrpath to remove its mistake:

$ chrpath -d library.so

$ chrpath -l library.so
library.so: no rpath or runpath tag found.

$ readelf -d library.so |grep PATH

$ nm library.so|grep var
0000000000003df8 d __frame_dummy_i/var/tmp


When asked to _remove_ the RUNPATH from a library, chrpath **does** remove the CORRECT entry, even though the string it previously inserted, and was reading back, was in an entirely different place. That string can't be removed by any means.

Note that this doesn't happen if chrpath is used on a library that was originally built with an rpath — it modifies those fine, assuming the new rpath is smaller than the original one. I also haven't yet seen it happen on executable files, even ones that patchelf has enlarged. So this is a fairly rare bug, fortunately.

Nevertheless, there does appear to exist at least the POTENTIAL for chrpath to incorrectly modify (perhaps even corrupt?) otherwise-working shared library objects, by attempting to insert RUNPATH strings at the wrong location in the binary.


Additional info:

I realize it doesn't entirely make sense to modify a library with patchelf, and then suddenly switch to chrpath for further modifications. That's kind of setting yourself up for problems.

But there certainly exists the possibility that a user could use chrpath to modify a library that _someone else_ had previously expanded using patchelf, not knowing that chrpath badly mishandles such libraries.