patchelf --remove-rpath leaves the rpath string the file

[ghost]

Describe the bug

After running patchelf --remove-rpath on a shared library, readelf -a | grep $OLD_RPATH will show no matches. However the string has been left behind in the binary.

Steps To Reproduce

Please include exact steps with an attached binary so that
another person can reproduce the problem.

patchelf --remove-rpath libgcc_s.so.1
readelf -a libgcc_s.so.1 | grep /nix/store/kvjzg
strings libgcc_s.so.1 | grep /nix/store/kvjzg
/nix/store/7rb10j6ifizp05pm2h51sjwiky5wnkb8-xgcc-11.3.0-lib/lib:/nix/store/kvjzg5xf51niicmw9fndxws1akgz21p4-bootstrap-stage0-glibc-bootstrap/lib:/nix/store/4b30jk1h42q5qs71l4sbv8cr3hnxdys4-bootstrap-tools/lib

Expected behavior

No output from the second command. Nix's reference scanner depends on this.

patchelf --version output

patchelf 0.15.0

libgcc_s.so.1.gz

Additional context

Add any other context about the problem here.

[ghost]

Temporary workaround is patchelf --set-rpath ""

[Mic92]

Just now it only removes the dyn section:

patchelf/src/patchelf.cc

Line 1400 in 5908e16

void ElfFile<ElfFileParamNames>::removeRPath(Elf_Shdr & shdrDynamic) {

it could also override the old string with XXX

[jvolkman]

Just now it only removes the dyn section:

patchelf/src/patchelf.cc

Line 1400 in 5908e16

void ElfFile<ElfFileParamNames>::removeRPath(Elf_Shdr & shdrDynamic) {

it could also override the old string with XXX

Isn't modifying the old value potentially dangerous? Is there anything that says multiple dyn entries can't refer to the same string in the table (or even the suffix of an existing string)?

[ghost]

Isn't modifying the old value potentially dangerous? Is there anything that says multiple dyn entries can't refer to the same string in the table (or even the suffix of an existing string)?

Yikes. That is probably the case.

[Mic92]

Isn't modifying the old value potentially dangerous? Is there anything that says multiple dyn entries can't refer to the same string in the table (or even the suffix of an existing string)?

Yes, you are right. I forgot about this optimization...

[ghost]

Isn't this a problem for --set-rpath as well?

Right now --set-rpath "" blanks the rpath:

patchelf/src/patchelf.cc

Lines 1566 to 1570 in e37f892

	if (rpath) {
	rpathSize = strlen(rpath);
	memset(rpath, 'X', rpathSize);
	}

[Mic92]

Isn't this a problem for --set-rpath as well?

I think it is. I am surprised it never got filed as an issue...

[eliasnaur]

Isn't this a problem for --set-rpath as well?

I think it is. I am surprised it never got filed as an issue...

Perhaps #162 is such an issue.

[ghost]

Perhaps #162 is such an issue.

Wow that looks highly likely to be the case.