Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 90886

Summary: dev-libs/libiconv has an RPATH starting with $PORTAGE_TMPDIR value (similar to GLSA 200503-01)
Product: Gentoo Security Reporter: René Rhéaume (a.k.a. repzilon, rener) <rene.rheaume>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: major CC: flameeyes, spb
Priority: High    
Version: unspecified   
Hardware: x86   
OS: All   
Whiteboard: ~3 [noglsa] jaervosz
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 81745    
Description Flags
libiconv-1.9.2-RPATH-fix-2.patch none

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:
>  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) gentoo-dev 2005-04-29 17:06:44 UTC
Created attachment 57629 [details, diff]

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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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 gentoo-dev 2005-04-29 21:11:25 UTC
cant we fix this without resorting to chrpath ?
Comment 7 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 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) gentoo-dev 2005-04-30 03:43:45 UTC
Created attachment 57664 [details, diff]

Whoever added the libtool support should be shot.
Comment 9 Martin Schlemmer (RETIRED) gentoo-dev 2005-04-30 03:53:50 UTC
Created attachment 57666 [details, diff]

This works also if you want the more minimal solution.
Comment 10 Diego Elio Pettenò (RETIRED) gentoo-dev 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) gentoo-dev 2005-05-11 07:19:13 UTC
As this is unstable -> closing with NO GLSA.