Bug 106548 - Openoffice 1.1 places '.' on LD_LIBRARY_PATH
Summary: Openoffice 1.1 places '.' on LD_LIBRARY_PATH
Status: CLOSED DUPLICATE of bug 102287
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: openoffice.org   
(Show other bugs)
Version: beta1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: David Lawrence
Depends On:
Blocks: CambridgeTarget
TreeView+ depends on / blocked
Reported: 2003-10-08 10:24 UTC by David Woodhouse
Modified: 2007-04-18 16:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-11 10:56:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
don't allow trailing : (2.45 KB, patch)
2004-11-01 15:52 UTC, Caolan McNamara
no flags Details | Diff

Description David Woodhouse 2003-10-08 10:24:48 UTC
hades /home/dwmw2 $ file libnsl.so.1
libnsl.so.1: ELF 32-bit LSB shared object, ARM, version 1 (ARM), stripped
hades /home/dwmw2 $ oowriter
Starting OpenOffice.org ...
/usr/sbin/lpc: error while loading shared libraries: libnsl.so.1: ELF file OS
ABI invalid
lpc: error while loading shared libraries: libnsl.so.1: ELF file OS ABI invalid
lpstat: error while loading shared libraries: libnsl.so.1: ELF file OS ABI invalid

Something is setting LD_LIBRARY_PATH to
/usr/lib/openoffice/program/local:/usr/lib/openoffice/program: (note the final
colon at the end which makes the current directory get searched).

This is probably exploitable.

OOI, why aren't these directories in the rpath of the executables which need
them? That would also allow prelinking to work.

Comment 1 Dan Williams 2003-10-08 13:12:31 UTC
Blizzard kept mentioning how evil rpath was :)  Seriously though, the code that
re-did the rpath for _every_ library in the 1.0.x specfile (all 100+ of them)
was really evil and I haven't merged it back into 1.1 yet.  Will do.

Comment 2 Caolan McNamara 2004-11-01 15:52:50 UTC
Created attachment 106019 [details]
don't allow trailing :

soffice.sh (which ends up as soffice) is the culprit for the trailing :.
Attached is a patch to fix it for 1.1.X

Comment 3 Caolan McNamara 2004-11-01 16:06:05 UTC
Upstream for 2.0 is http://www.openoffice.org/issues/show_bug.cgi?id=36463

Comment 4 Dan Williams 2004-11-01 16:27:21 UTC
Are we sure this works and won't break by not being able to find

Comment 5 Caolan McNamara 2004-11-01 16:43:02 UTC
Yeah. The current case does not actually explictly add the cwd to
LD_LIBRARY_PATH. Consider the case of someone right now with a
LD_LIBRARY_PATH set to e.g. /tmp/uselessfoobar before they run oofice,
in this scenario it ends up as "correctooodirs:/tmp/uselessfoobar".
i.e. without the cwd being added to the LD_LIBRARY_PATH, cwd is only
getting added as a side effect when there happens to be no initial
LD_LIBRARY_PATH. Anyway I tried it after making the change and it
worked, as did the edge case of deleting ~/.rhopenoffice1.1 and
running ooffice which runs setup and running it then.

Comment 6 David Woodhouse 2004-11-01 16:57:45 UTC
But shouldn't the OOo executables and library have an explicit runpath
anyway, in order to ensure that prelinking actually works? 

Would it be better to refrain from setting LD_LIBRARY_PATH altogether,
so that any subtle bugs in the setting of the runpath actually make
themselves known?

Comment 7 Caolan McNamara 2004-11-01 17:11:44 UTC
Methinks rpath is a seperate issue, logged by yourself as #122113# :-)
(prelink as #102287#). The task at hand here is just any potential
exploitablity arising out of a LD_LIBRARY_PATH that can include cwd

Comment 8 David Woodhouse 2004-11-01 17:12:57 UTC
True. I was thinking holistically -- why not just stop setting
LD_LIBRARY_PATH altogether? 

Comment 9 Dan Williams 2004-11-08 14:53:46 UTC
Bug 102287 seems to incorporate the fix for this issue by using rpath

*** This bug has been marked as a duplicate of 102287 ***

Comment 10 Caolan McNamara 2004-11-11 10:56:31 UTC
close as duplicate

Note You need to log in before you can comment on or make changes to this bug.