https://bugzilla.novell.com/show_bug.cgi?id=706670 https://bugzilla.novell.com/show_bug.cgi?id=706670#c5 --- Comment #5 from Martin Konold <external.martin.konold@de.bosch.com> 2011-07-19 18:04:48 CEST --- Hi Sebastian, please REOPEN this bug. Thanks for taking care about this issue.
I think this is documented behavior and why wrapper scripts were fixed accordingly (for example see bnc#642830).
I can see that in bnc#642830 the issue is worked around in tomboy. I cannot access bnc#187055. Can you please show me where the current behavior is documented? After all it breaks user space between releases without a rational?! Actually looking at conventionally available documentation like http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html I get the impression that the newly introduced current behavior is not intended and leads to the described security issue. Or lets rephrase it: I so far could not find documentation (e.g. man ld.so) which gives good reasons for the new semantics of LD_LIBRARY_PATH this includes neither documentation/standardization which requires this change nor a practical use case which make the new behaviour mandatory. On the other hand there are obvious unnecessary security issues introduced beyond the already existing and well understood issue. Of course I am willing to learn that I am proven wrong. Please provide me some pointer to read about the rational for the change in semantics of LD_LIBRARY_PATH as interpreted by ld.so. Yours, -- martin P.S.: man ld.so reads "LD_LIBRARY_PATH A colon-separated list of directories in which to search for ELF libraries at execution-time. Similar to the PATH environment variable." There is nothing in the Linux PATH variable documentation which implies that the newly introduced behavior is mandatory. Actually continuing from the above reference in the ld.so manual I looked up the definition of the PATH environment variable in the good old IEEE Std 1003.1, 2004 Edition standard POSIX documentation. This documentation indeed describes the new semantic explicitly as a "A zero-length prefix is a legacy feature that indicates the current working directory [...] A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH." I think there are excellent reasons why POSIX deprecated the old semantic and defined the old ld.so semantic as "conforming". I therefore believe that this bug is indeed a regression. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.