Bug 90886 – dev-libs/libiconv has an RPATH starting with $PORTAGE_TMPDIR value (similar to GLSA 200503-01)

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description René Rhéaume (a.k.a. repzilon, rener) 2005-04-29 11:52:44 UTC]

I emerged libiconv to be able to build glib2 on a uclibc-based install. Few days later, I checked my system using a script I made and I got this output:

>Searching ELF binaries on the system. It will take a while.
>These binaries have RPATH set:
>/usr/bin/iconv
>  RPATH       /var/tmp/portage/libiconv-1.9.2/image//usr/lib

I also ran readelf on it
$ readelf -d /usr/bin/iconv | egrep 'RPATH|RUNPATH'
 0x0000000f (RPATH)                      Library rpath: [/var/tmp/portage/libiconv-1.9.2/image//usr/lib]
 0x0000001d (RUNPATH)                    Library runpath: [/var/tmp/portage/libiconv-1.9.2/image//usr/lib]

This is similar to bug #75181 , a.k.a GLSA 200503-01. Gentoo BSD team should be informed of this bug as soon as possible.

Reproducible: Always
Steps to Reproduce:




Expected Results:  
No insecure RPATH is hard-coded into /usr/bin/iconv

[Comment 1 René Rhéaume (a.k.a. repzilon, rener) 2005-04-29 12:36:22 UTC]

I originnaly thought a dosed or a patch would do the trick. Unfortunately, this issue more arcane. I found out that if libiconv was not installed (whether never on unmerged prior to emerging), the iconv executable will contain an RPATH. But if I emerge again without prior unmerging (a rebuild), RPATH is gone!

[Comment 2 solar (RETIRED) 2005-04-29 17:06:44 UTC]

Created attachment 57629 [details, diff]
libiconv-1.9.2-chrpath-ebuild.patch

This patch makes use of the chrpath command to remove the rpath in the
src_install() phase. chrpath is tiny (13k)

[Comment 3 Diego Elio Pettenò (RETIRED) 2005-04-29 20:07:33 UTC]

I'm going to test if chrpath works on g/fbsd, if it doesn't we need to find a new way to handle this.

Please next time cc me as I'm libiconv's maintainer.

[Comment 4 Diego Elio Pettenò (RETIRED) 2005-04-29 20:10:50 UTC]

Seems like the problem isn't there on g/fbsd but just on linux.
Need KERNEL USE_EXPANDED to fix this, really need that ASAP now.

[Comment 5 Diego Elio Pettenò (RETIRED) 2005-04-29 20:23:33 UTC]

Added a new revision which uses chrpath unconditionally but is masked on fbsd, waiting to have KERNEL in USE_EXPAND.


Added sparc to cc as I had to drop ~sparc keyword as it misses chrpath.

[Comment 6 SpanKY 2005-04-29 21:11:25 UTC]

cant we fix this without resorting to chrpath ?

[Comment 7 Sune Kloppenborg Jeppesen (RETIRED) 2005-04-29 23:44:26 UTC]

Diego, we normally CC people on any security bugs as soon as it gets wrangled, which is now. Solar was just faster than me this time around.

[Comment 8 Martin Schlemmer (RETIRED) 2005-04-30 03:43:45 UTC]

Created attachment 57664 [details, diff]
libiconv-1.9.2-RPATH-fix.patch

Whoever added the libtool support should be shot.

[Comment 9 Martin Schlemmer (RETIRED) 2005-04-30 03:53:50 UTC]

Created attachment 57666 [details, diff]
libiconv-1.9.2-RPATH-fix-2.patch

This works also if you want the more minimal solution.

[Comment 10 Diego Elio Pettenò (RETIRED) 2005-04-30 04:31:07 UTC]

Thanks I've added your patch and libiconv is happy both on linux and fbsd.

It also has again the ~sparc keyword.

[Comment 11 Sune Kloppenborg Jeppesen (RETIRED) 2005-05-11 07:19:13 UTC]

As this is unstable -> closing with NO GLSA.