Name: gm110360 Date: 09/11/2002


FULL PRODUCT VERSION :
Java(TM) 2 Euntime Environment, Standard aEdition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)



FULL OPERATING SYSTEM VERSION :Linux lnxbld 2.4.2-2smp #1
SMP Sun Apr 8 10:21:34 EDT 2001 i686 unknown
glibc-2.2.2-10
Red Hat Linux release 7.1 (Seawolf)


ADDITIONAL OPERATING SYSTEMS :Linux Suse 7.3



A DESCRIPTION OF THE PROBLEM :
Our product needs to run Java in setuid. After we upgraded
to the 1.4 JVM our product no longer ran. We support
Solaris 8 and 9 as well and have not observed this problem
on Solaris. Upon investigation we found that by setting
java (chmod ugo+s java) and then invoking (Linux
only) "java -version" it appears to hang with no visable
output, you must the cntl-C to abort the program. Remove
the setuid bit chmod ugo-s java and java -version displays
the version information. Following is what we found.

 It appears that the java executable sets the
LD_LIBRARY_PATH environment variable and then it execs,
calling the same executable again. Upon the second entry,
it appears to check if LD_LIBRARY_PATH is okay and, if it
is, the actual JVM is will be fired up.
 
Unfortunately, when java is in setuid mode, someone felt
the need to unset the LD_LIBRARY_PATH environment variable
before exec-ing. I noticed, because even the values we
assign to LD_LIBRARY_PATH are lost.
 
Example:
 
File /tmp/dbg.sh:
 
#!/bin/sh
echo "LD_LIBRARY_PATH=$LD_LIBRARY_PATH"

The proof of the pudding:
 
[richardg@MrLinux bin]$ chmod +x /tmp/dbg.sh
[richardg@MrLinux bin]$ export DEBUGPROG=/tmp/dbg.sh
[richardg@MrLinux bin]$ export LD_LIBRARY_PATH=/usr/tmp
Sample test value
[richardg@MrLinux bin]$ $DEBUGPROG
LD_LIBRARY_PATH=/usr/tmp
Proof that DEBUGPROG works
[richardg@MrLinux bin]$ ls -l java
-rwsr-xr-x 1 richardg novell 23380 Aug 8 02:37
java Setuid mode to richard
[richardg@MrLinux bin]$ id
uid=166(richardg) gid=204(novell) groups=204(novell),205
(beav_rd) Current id=richardg, no setuid switch
[richardg@MrLinux bin]$ ./java -
version Run java non-setuid
LD_LIBRARY_PATH=/home2/richardg/tmp/j2re1.4.1-
i586/lib/i386/client:/home2/richardg/tmp/j2re1.4.1-
i586/lib/i386:/home2/richardg/tmp/j2re1.4.1-
i586/../lib/i386:/usr/tmp LD_LIBRARY_PATH extended, and
test value /usr/tmp still there.
[richardg@MrLinux bin]$ su pvcs Activate setuid
by switching to non-owner ID
Password:
bash-2.05$ export LD_LIBRARY_PATH=/usr/tmp Reassign sample
test value lost during "su"
bash-2.05$ $DEBUGPROG Proof that
DEBUGPROG still works
LD_LIBRARY_PATH=/usr/tmp
bash-2.05$ ./java -version Run java in
setuid mode
LD_LIBRARY_PATH= LD_LIBRARY_PATH
is GONE

 
So java is continuously calling itself, because the
requirement to launch the actual JVM (LD_LIBRARY_PATH
properly set) will never be met.
 
Note: our DEBUGPROG is obviously non-functional, since it
doens't call the actual JVM, but it serves to prove the
problem.


REGRESSION. Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.goto the directory where java launcher resides.
2.chmod ugo+s java
3.java -version

EXPECTED VERSUS ACTUAL BEHAVIOR :
Java version information should be displayed


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
We used the launcher provided with the 1.3.1 JVM and rename
the 1.4.0 launcher to java.orig. This is a less than
optimal workaround but for the short term works.

Release Regression From : 1.3.1_04
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.

(Review ID: 164318)
======================================================================