PRB: SecurityExceptionEx Exception Running a Java Applet

Last reviewed: January 29, 1998
Article ID: Q175622
The information in this article applies to:
  • SDK for Java, version 2.0, 2.01
  • Microsoft Internet Explorer (Programming), version 4.0, 4.01
  • Microsoft Win32 Virtual Machine for Java

SYMPTOMS

When running a Java applet, the security manager throws one of the following exceptions:

   com.ms.security.SecurityExceptionEx[classname.methodname]

   com.ms.security.SecurityExceptionEx[Host]

   com.ms.security.SecurityExceptionEx[Unknown]

   java.lang.SecurityException: J/Direct method has not been authorized for
   use on behalf of an untrusted caller.

CAUSE

  • A SecurityExceptionEx[methodname.classname] will occur if your applet attempts to perform a trusted operation and is not trusted.
  • A SecurityExceptionEx[Host] will occur if the Web browser invoked a method that performs a trusted operation and that method did not first assert its permission to perform the trusted operation. This situation will occur if your applet performs trusted operations in the applets default constructor, init(), start(), stop() or destroy() method without first asserting its permissions.
  • A SecurityExceptionEx[Unknown] will occur if the script engine invoked a method that performs a trusted operation, and that method did not first assert its permission to perform the trusted operation. This situation will occur if your applet has a public method called by VBScript or JScript, and that method performs trusted operations without first asserting its permissions.
  • A "java.lang.SecurityException: J/Direct method has not been authorized for use on behalf of an untrusted caller" will occur if the Web browser or script engine invoked a method that makes a J/Direct call, and that method did not first assert its permission to perform the trusted operation.

RESOLUTION

If a SecurityExceptionEx[methodname.classname] occurs, you must sign your applet to enable it to perform operations outside of the Java sandbox. For more information please see the documentation in the Microsoft SDK for Java 2.0 or 2.01. (NOTE: You must sign your cabinet file with the appropriate permissions. -Low or -LowX permission will guarantee you have appropriate access or you may sign with the appropriate granular permissions using an ini file passed to Signcode.exe).

If a SecurityExceptionEx[Host], SecurityExceptionEx[Unknown], or "java.lang.SecurityException: J/Direct method has not been authorized for use on behalf of an untrusted caller" and you are sure your caller cannot do harm if your trusted operation is performed, you can do one of the following:

  • Assert your permission using the PolicyEngine class. (NOTE: The lifetime of PolicyEngine.assertPermission() is the same as the lifetime of the method in which it is called. Once the method that asserts its permission returns , you would need to re-assert permissions as needed.)
  • Spawn a separate thread to perform the trusted operation, giving the thread permission to perform the operation.

STATUS

This behavior is by design.

MORE INFORMATION

In the Microsoft Virtual Machine (VM) for Java (build 2252 or higher) that is included in the SDK for Java 2.0/2.01 and Internet Explorer 4.0/4.01, the security manager now crawls the call stack when an applet is run from a signed cabinet file. This behavior is new in this build of the VM, and helps ensure that the applet author is aware of the security risks of untrusted code manipulating their applet. By asserting an applet's permission, the programmer is acknowledging that they understand the security risks and have taken all measures possible to protect the user's system.

When trusted operations are performed, the security manager ensures the object is trusted to perform the operation, and then the call stack is crawled to ensure all callers are also trusted to make the call. A SecurityExceptionEx[Host] or SecurityExceptionEx[Unknown] exception will be thrown if an untrusted caller is found on the call stack.

The assertPermission(PermissionId pid) method in the PolicyEngine class will prevent the security manager from crawling the call stack, enabling your applet to perform trusted operations even when methods on the call stack are not trusted. You should only assert your permission if you are sure an untrusted member of the call stack cannot harm the users system. A logical place to assert your permissions is at the beginning of the method that is making the trusted call. Once this method returns, subsequent public methods called from outside the virtual machine will also need to assert permission before making trusted calls.

The PermissionID class has predefined granular permissions, such as NETIO, FILEIO, and so forth. In order to grant full permissions to the applet use the SYSTEM permission. This is needed for calling J/Direct, COM, and native methods.

The following sample applet demonstrates reading a character from a Web page, which is a trusted operation. This example needs to be trusted either by placing the file in a signed cabinet file, running the project from Developer Studio, or by placing the class in the classpath:

   import com.ms.security.*;

   import java.applet.Applet;
   import java.net.*;
   import java.io.*;
   import java.awt.*;

   public class myApplet1 extends Applet {
     TextField message=null;

     public myApplet1() {
       message=new TextField();
       setLayout(new BorderLayout());
       add("Center",message);
     }

     public void init()
    {
       /*
         Our init function needs to read a character from a URL, which is a
         trusted operation.  We assert NET permission to stop the stack
         crawling since the Web page isn't trusted.  The applet must be
         signed so the init() function has permission to perform net
        operations.
       */
       try {
         if (Class.forName("com.ms.security.PolicyEngine") != null) {
           PolicyEngine.assertPermission(PermissionID.NETIO);
         }
       } catch (Throwable cnfe) {
       }

       try {
         URL url = new URL("http://www.microsoft.com/");
         DataInputStream dis;
         dis = new DataInputStream(url.openConnection().getInputStream());
         dis.readChar();
         message.setText("Read character.");
       } catch (MalformedURLException mue) {
         message.setText("MalformedURL");
         mue.printStackTrace();
       } catch (Throwable t) {
         message.setText(t.toString());
         t.printStackTrace();
       }
     }
   }

REFERENCES

For more information on using the com.ms.security package, see the Microsoft SDK for Java 2.x documentation.

For more information on signing a Java cabinet file, see the Microsoft SDK for Java 2.x documentation.

For the latest Knowledge Base articles and other support information on Visual J++ and the SDK for Java, see the following page on the Microsoft Technical Support site:

   http://support.microsoft.com/support/visualj/
   http://support.microsoft.com/support/java/

Keywords          : kbcode JVM
Technology        : kbInetDev
Version           : WINDOWS:2.0,2.01,4.04.01
Platform          : WINDOWS
Issue type        : kbprb


================================================================================


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: January 29, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.