JDK-7029048 : (launcher) fence the launcher against LD_LIBRARY_PATH
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-03-18
  • Updated: 2019-01-16
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b140Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
With the purging of the LD_LIBRARY_PATH via 6367077, the JDK7 launcher is
vulnerable to the LD_LIBRARY_PATH picked up an ambient java on the path.
For example supposing ant is run with jdk6 to invoke a jdk7 exe say javac
then the LD_LIBRARY_PATH settings in the parent will be available to the
child. Due to the way the Solaris rtld works the libraries on the LLP
will take preceded over the libraries in jdk7, thus both libraries 
could exist in the process address space, thus this will lead to 
bizarre and unpredictable error conditions. See 6913237.
Though we are planning on Release noting this, the launcher must take
a defensive approach.
Ideally yes, 7021644 would be the right/ideal approach, but there seems
to be some issues with implementing that.

I think once the drive/path is on the LLP, the system will hit it
with stat(2), access(2), open(2) and mmap(2) calls on it. So what we
are doing here is adding one more stat call, more than likely it
will be lost in translation, considering the fact that rt.jar needs
to be loaded.

Comments
EVALUATION It is not clear what the use case of this is, and how widespread, regardless it would be better to take a defensive approach and have the launcher test the LD_LIBRARY_PATH values (and its variants LLP32/LLP64), for the existence of libjvm.so, if positive then cause the launcher to set the environment variable for the intended JRE and re-exec.
18-03-2011