Bug 106548
| Summary: | Openoffice 1.1 places '.' on LD_LIBRARY_PATH | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | David Woodhouse <dwmw2> | ||||
| Component: | openoffice.org | Assignee: | Dan Williams <dcbw> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | beta1 | CC: | caolanm, chris.ricker | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-11-11 10:56:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 100644 | ||||||
| Attachments: |
|
||||||
|
Description
David Woodhouse
2003-10-08 10:24:48 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. 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
Upstream for 2.0 is http://www.openoffice.org/issues/show_bug.cgi?id=36463 Are we sure this works and won't break by not being able to find libraries? 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. 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? 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 True. I was thinking holistically -- why not just stop setting LD_LIBRARY_PATH altogether? Bug 102287 seems to incorporate the fix for this issue by using rpath instead. *** This bug has been marked as a duplicate of 102287 *** close as duplicate |