JDK-8166366 : StackOverflowError with custom security manager
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u92
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2016-08-26
  • Updated: 2018-02-20
  • Resolved: 2018-02-20
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

EXTRA RELEVANT SYSTEM CONFIGURATION :
apache tomcat 8.0.33

A DESCRIPTION OF THE PROBLEM :
This is a duplicat of http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8143222. The latter report states a fix in version  8u65 b02, but the problem does still exist in java 1.8.0_92.

The problem exists wether run in a cygwin environment or plain windows. My further description will use the cygwin conventions.

I wrote a custom SecurityManager overwriting the checkPermission Method to only catch AccessControlException and write it to stdout. The Source is documented in JDK-8143222.

The jar containing the custom SecurityManager resides in the JRE_HOME/lib/ext directory. The custom policy file does NOT replaces the default java.policy file. The logs verify that both policy Files were read, hence I expect my custom SecurityManager to run with AllPermission. Changing my policy file to only contain a single grant with AllPermission does not change anything.

The Application is a webapp running in tomcat. I set the JAVA_OPTS in $TOMCAT_HOME/bin/setenv.sh like this:

JAVA_OPTS="-Djava.security.manager=de.kvb.common.security.manager.KvbSecurityManager -Djava.security.policy=c:/tmp/secmgrtest.policy -Djava.security.debug=access,policy,scl





STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Write a custom SecurityManager (that does nothing) and  put the containing jar file into the JRE_HOME/lib/ext directory.

Write a custom policy file containing the only entry 

grant  {
	permission java.security.AllPermission;
};	

Start tomcat with  JAVA_OPTS="-Djava.security.manager=<yoursecuritymanagerclass> -Djava.security.policy=<yourcustompolicyfile> -Djava.security.debug=access,policy,scl"

(JAVA_OPTS ist usually set in a file named setenv.sh or setenv.bat in tomcat/bin directory.)
start tomcat with the SecurityManager turned on.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The webapplication should run, logging missing permissions to catalina.out.
ACTUAL -
tomcat stops with a StackOverflowError in catalina.out.


        

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.StackOverflowError
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.FilePermission.init(FilePermission.java:203)
        at java.io.FilePermission.<init>(FilePermission.java:277)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:888)

        at java.io.File.isDirectory(File.java:844)
        at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:269)
        at sun.security.provider.PolicyFile.canonicalizeCodebase(PolicyFile.java:1735)
        at sun.security.provider.PolicyFile.access$700(PolicyFile.java:258)
        at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1188)
        at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1186)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1185)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1132)
        at sun.security.provider.PolicyFile.implies(PolicyFile.java:1086)
        at java.security.ProtectionDomain.implies(ProtectionDomain.java:281)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:450)
        at java.security.AccessController.checkPermission(AccessController.java:884)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at de.kvb.common.security.manager.KvbSecurityManager.checkPermission(KvbSecurityManager.java:30)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
       
	at java.io.File.isDirectory(File.java:844)
        at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:269)
        at sun.security.provider.PolicyFile.canonicalizeCodebase(PolicyFile.java:1735)
        at sun.security.provider.PolicyFile.access$700(PolicyFile.java:258)
        at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1188)
        at sun.security.provider.PolicyFile$5.run(PolicyFile.java:1186)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1185)
        at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1132)
        at sun.security.provider.PolicyFile.implies(PolicyFile.java:1086)
        at java.security.ProtectionDomain.implies(ProtectionDomain.java:281)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:450)
        at java.security.AccessController.checkPermission(AccessController.java:884)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at de.kvb.common.security.manager.KvbSecurityManager.checkPermission(KvbSecurityManager.java:30)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:888)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package de.kvb.common.security.manager;

import java.security.AccessControlException;
import java.security.Permission;


public class KvbSecurityManager extends SecurityManager {

   
    @Override
    public void checkPermission(Permission perm) {

        try {
            super.checkPermission(perm);
        } catch(AccessControlException e) {
        	e.printStackTrace();
        }

    }

}

---------- END SOURCE ----------


Comments
The issue is reproducible with jdk of versions: 8u112-8u162, but not with 8u172. So, it seems to be a duplicate of JDK-8191649 which was resolved via JDK-8193156
20-02-2018

Need to check, if the issue is manifesting itself with the latest update release. The fix for JDK-8085903 was done so that it should avoid the regression caused by JDK-8143222.
21-11-2017