Java Solaris Communities Sun Store Join SDN My Profile Why Join?
» search tips 
Sun Developer Network
Developers Home > Products & Technologies > Java Technology > Community > Bug Database >
Join SDNWhy Join
 
Bug Database
Bug Detail
Quick Lists
-  Top 25 Bugs
-  Top 25 RFE's
-  Recently Closed Bugs
Printable Page Printable Page


Bug Database
Welcome
 
»  Login
»  Report a Bug
»  FAQs
  Bug Watch List:
» Watch this Bug
 Bug Votes:
» Vote for this Bug
Bug ID: 6203567
Votes 80
Synopsis NameService resolving in Applet causes AccessControlException and deadlock
Category idl:other
Reported Against
Release Fixed
State 6-Fix Understood, bug
Priority: 4-Low
Related Bugs 6256201
Submit Date 03-DEC-2004
Description 
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux mjirko 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 athlon i386 GNU/Linux
 customer  Windows 2000 [Verze 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
NameService resolving (calling ORB.resolve_initial_references("NameService")) in Apllet causes AccessControlException and deadlock (applet hangs).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- run name service (on port 2809):  tnameserv -ORBInitialPort 2809
- run test applet using appleviewer:  appletviewer CorbaTest.html

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
NameSrvice should be resolved and message "Nameservice resolved." printed into System.out.
ACTUAL -
The applet hangs in ORB.resolve_initial_references().

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "Thread-2" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
        at java.security.AccessController.checkPermission(AccessController.java:427)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at sun.applet.AppletSecurity.checkAccess(AppletSecurity.java:138)
        at java.lang.Thread.checkAccess(Thread.java:1218)
        at java.lang.Thread.setName(Thread.java:1001)
        at com.sun.corba.se.impl.transport.SelectorImpl.run(SelectorImpl.java:239)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
<!-- FILE: CorbaTest.html -->
<HTML>
  <HEAD>
    <TITLE>CORBA Test</TITLE>
  </HEAD>
  <BODY>
    <h1>CORBA Test</h1>
    <hr>
    <applet code="CorbaTest.class" width="400" height="250">
      <param name="org.omg.CORBA.ORBInitialPort" value="2809"/>
      alt="Your browser understands the &lt;APPLET&gt; tag but isn't running the applet, for some reason."
      Your browser is completely ignoring the &lt;APPLET&gt; tag!
    </applet>
  </BODY>
</HTML>


/**
 * FILE: CorbaTest.java
 */
import java.applet.Applet;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;

public class CorbaTest extends Applet {

  private ORB orb;

  public void init() {
    // create ORB
    try {
      orb = ORB.init(this, null);
      //((com.sun.corba.se.spi.orb.ORB) orb).transportDebugFlag = true;
    } catch(RuntimeException e) { }
  }

 public void start() {
    if(orb==null) return;
    // resolve NamingContext
    try {
      org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
      NamingContext nc = NamingContextHelper.narrow(objRef);
      System.out.println("NameService resolved.");
    } catch(Exception e) { }
  }

  public void destroy() {
    if(orb!=null) {
      orb.shutdown(false);
      orb = null;
    }
  }

}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Grant "modifyThread" and "modifyThreadGroup" permissions to Applet.
Posted Date : 2005-11-10 19:10:59.0

Suggested fix supplied by community member   xxxxx@xxxxx  :

A DESCRIPTION OF THE FIX :
  Bug number : 6203567
  Bug Description : NameService resolving in Applet causes AccessControlException and deadlock
Diff Baseline : Tiger  b05
Diff :
--- com/sun/corba/se/impl/transport/SelectorImpl.java   2005-08-26 22:54:33.000000000 +0200
+++ com/sun/corba/se/impl/transport/SelectorImpl2.java  2005-11-10 10:23:42.000000000 +0100
@@ -236,7 +236,12 @@

     public void run()
     {
-       setName("SelectorThread");
+       AccessController.doPrivileged(new PrivilegedAction() {
+           public Object run() {
+               setName("SelectorThread");
+               return null;
+           }
+       });
        while (!closed) {
            try {
                int n = 0;

FIX FOR BUG NUMBER:
6203567
Posted Date : 2005-11-10 19:10:59.0

Test case supplied by community member   xxxxx@xxxxx  :

Hello,

here is a little test case for the fix.  Steps to use this test case:

1) compile CorbaInAppletTest.java
2) run name service (on port 2809):  tnameserv -ORBInitialPort 2809
3) run the test applet using appleviewer:  appletviewer 
CorbaInAppletTest.html

If the bug is present, the exception message is printed out and the 
apllet hangs in ORB.resolve_initial_references().
If the bug is corrected, NameSrvice should be resolved and message 
"Nameservice resolved." printed into System.out.


Refer to the attached files for CorbaInAppletTest.java and CorbaInAppletTest.html
Posted Date : 2005-11-11 22:46:05.0
Work Around 
N/A
Evaluation 
Yes, this should be fixed. We plan on fixing it for the next update release of Java SE 5.0.
Posted Date : 2005-11-18 01:11:48.0

Contribution-Forum:https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=12008&forumID=1463
Posted Date : 2006-03-15 04:12:53.0
Comments
  
  Include a link with my name & email   

Submitted On 19-APR-2005
vanitha2002us_java 
I am facing same problem. The suggested workaround is only  working when I didn't give "codeBase URL" with the grant policy entry.
could you please tell me if it is the same case with you. If not could you please send me the policy file. 

-- vanitha2002us@yahoo.com


Submitted On 20-OCT-2005
dhauck 
Does Sun realize this makes all Java 1.3/1.4 CORBA-based applets dead in the water when run under 1.5? The only workaround is to grant privileges or to sign applets, which for many users precludes running the applet. We've run this down in the Java source it appears that this can be correctly by simply *not* setting thread names for CORBA threads. Alternatively is there really no way to isolate the setting of thread names from the modifyThread/modifyThreadGroup permission (i.e., is it really all that much or a security issue to allow applets ot modify thread names, or is the inclusion of this security attribute just an orthogonality issue wrt other thread modification attributes?). Can we please get this fixed? 
-David


Submitted On 09-NOV-2005 
this is causing our customer severe pain, as upgrading to 1.5 isn't feasible right now.


Submitted On 09-NOV-2005 
We have a deep need for CORBA-based applets.


Submitted On 09-NOV-2005 
I wish I could use CORBA-based applets under 1.5


Submitted On 09-NOV-2005 
There is definitely a need for this fix for the benefit of my company.


Submitted On 09-NOV-2005 
I hope this gets repaired soon.


Submitted On 09-NOV-2005 
This fix is very important


Submitted On 09-NOV-2005 
Please fix this issue


Submitted On 09-NOV-2005 
Please fix this issue as quickly as possible. Thank you.


Submitted On 09-NOV-2005 
This bug is causing a major problem.  Please fix.


Submitted On 09-NOV-2005 
This bug has created big headache for us. Pleas put the fix on top of your queue. Thanks


Submitted On 09-NOV-2005 
We need to get a  bug fix for this problem ASAP. Thanks


Submitted On 09-NOV-2005 
I have concured with other users running into the same problem stated here. Please raise the priority to fix this problem. Regards.. MAR


Submitted On 10-NOV-2005
mjirkovsky@cominfo.cz 
SUN hasn't been able to fix this bug within 1 year, so I decided to fix it myself. I sent suggested bugfix to SUN this morning. I hope SUN will approve my bugfix and include it in the next Tiger update (b06).


Submitted On 14-NOV-2005 
This is a real problem - please fix this ASAP


Submitted On 14-NOV-2005 
Please incorporate a fix; this is an urgent need


Submitted On 14-NOV-2005 
Get er done


Submitted On 14-NOV-2005 
We need this fixed
ITT-AES


Submitted On 14-NOV-2005 
Please


Submitted On 21-NOV-2005 
This is holding up installation of operational software, please remedy this asap.


Submitted On 21-NOV-2005 
This issue needs to be addressed to maintain the integrity of the Java Environment.


Submitted On 03-JAN-2006 
This problem is severe enough that one of our system developers has asked its customers to request a prompt fix for the problem.  Please make it a priority!


Submitted On 09-JAN-2006 
Please make this bug fix a priority.  We have software written using CORBA-based Java applets which is vital for our mission objectives.  We need to use these applets under version 1.5.


Submitted On 10-JAN-2006 
Sun's evaluation says that "We plan on fixing it for the next update release of Java SE 5.0.". However, JRE version 1.5.0_06 has now been released and this bug still has not been fixed.


Submitted On 12-JAN-2006
vanitha2002us_java 
We have multiple java products (Uses JAVA APPLETS), some work in only java 1.4.2_XX , and some in Java 1.5. Unless this and (Bug ID 6333993 )is fixed we can't migrate to 1.5. Is it possible to have both JRE 1.4.2_XX and JRE 1.5 on the same machine and allow user to choose the JRE for the application to run in??
-- vanitha2002us@yahoo.com


Submitted On 30-MAR-2006 
I wish I could use CORBA-based applets under 1.5


Submitted On 30-MAR-2006 
Please make this bug fix a priority.  We have software written using CORBA-based Java applets which is vital for our mission objectives.  We need to use these applets under version 1.5.


Submitted On 31-MAR-2006 
The fix for this bug is a trivial and non-perturbing source code change, and the source code fix has already been submitted to Sun verbatim.  Sun agreed to put this fix in a JRE 1.5 patch release six months ago, and it still has not happened.


Submitted On 28-JUN-2006
mjirkovsky@cominfo.cz 
I'v just tested JRE 1.6.0-beta2 and found out that this bug is still presented in this version of J2SE. So I think SUN won't correct this bug until someone pays for it.


Submitted On 14-MAR-2007 
I would like this bug to be fixed as well. I have reproduced this bug myself :-(  before finding it here. Really strange we have it !


Submitted On 12-APR-2007
synkronix 
Please fix!


Submitted On 05-NOV-2007
veepee09 
I tried with JRE 1.6.0_03 and the bug (resolve_initial_references) still exists. The workaround of granting modifyThread and modifyThreadGroup works but asking the users to change their policy files doesn't make sense. Is there any other way to overcome this issue. I tried doPriviliged around setName method but doesn't help in fixing this issue. Any help is greatly appreciated.



PLEASE NOTE: JDK6 is formerly known as Project Mustang





About Sun  |  About This Site  |  Newsletters  |  Contact Us  |  Employment
How to Buy  |  Licensing  |  Terms of Use  |  Privacy  |  Trademarks
 

 
Copyright 1994-2008 Sun Microsystems, Inc.
A Sun Developer Network Site

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
 
XML Content Feeds