0

I'm attempting to deploy a WAR to Tomcat and running into problems with the Java Security Manager. This is Tomcat 7.0.55 running Java 1.8.0, and Tomcat is started with parameters like this:

-Dcatalina.base="/path/to/apache-tomcat-7.0.55"
-Dcatalina.home="/path/to/apache-tomcat-7.0.55"
-Djava.endorsed.dirs="/path/to/apache-tomcat-7.0.55\endorsed"
-Djava.security.manager
-Djava.security.policy="/path/to/config/custom_catalina.policy"

The important thing here is that it's enabling the Java Security Manager and then pointing it at a custom security policy, which looks like this:

grant {
    permission java.security.AllPermission;
};

It seems like this should result in the rather pointless configuration of activating the security manager and then telling it to just allow everything (I don't run the server so don't blame me!). However, when I deploy my WAR it fails with several stack traces containing things like:

Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) ~[?:1.8.0_51]
    at java.security.AccessController.checkPermission(AccessController.java:884) ~[?:1.8.0_51]
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) ~[?:1.8.0_51]
    at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) ~[?:1.8.0_51]
    at java.lang.System.getProperty(System.java:753) ~[?:1.8.0_51]
    at org.apache.commons.lang3.JavaVersion.maxVersion(JavaVersion.java:196) ~[commons-lang3-3.4.jar:3.4]

I've tried explicitly granting AllPermission to my own application with something like:

grant codeBase "file:${catalina.home}/webapps/myApp/-" {
    permission java.security.AllPermission;
};

and even explicitly granting the PropertyPermission to read java.version. None of it makes any difference. The same AccessControlExceptions still get thrown and prevent deployment.

What is going on here? How can I troubleshoot this?

jpappe
  • 365
  • 4
  • 12
  • Did you ever solve this? – PhilW Mar 03 '17 at 21:03
  • Alas, no. The "solution" was to disable the Security Manager. – jpappe Mar 13 '17 at 16:33
  • Thanks for the reply! Did/does your code happen to use the ForkJoinPool? This is what caused the issue for me. "If a SecurityManager is present and no factory is specified, then the default pool uses a factory supplying threads that have no Permissions enabled" – PhilW Mar 13 '17 at 20:24

1 Answers1

0

Ours was not coming during deployment, rather while heavy load testing.

We changed the Connector in server.xml from Nio2 to Nio and it solved problem for us org.apache.coyote.http11.Http11NioProtocol (The first version of NIO, instead of NIO2).

We didn't disable tomcat security manager, that is against our firm's policy.

Sandeep Khantwal
  • 191
  • 1
  • 7