Javadoc: http://java.sun.com/javase/6/docs/api/java/security/Policy.html#getPermissions (java.security.CodeSource) Policy Javadoc says that method getPermissions(java.security.CodeSource) is optional and policies do not have to implement it. At least nobody said that returned collection will be editable. So to avoid exceptions a possible solution is to check whether permissions can be added before trying to do that. Stacktrace: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object at java.security.Permissions.add(Permissions.java:110) at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:790) at org.apache.jasper.compiler.JspRuntimeContext.initSecurity (JspRuntimeContext.java:487) at org.apache.jasper.compiler.JspRuntimeContext.<init> (JspRuntimeContext.java:142) at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:121)
(In reply to comment #0) How can I reproduce this situation? Do you have any test cases?
(In reply to comment #1) > (In reply to comment #0) > How can I reproduce this situation? Do you have any test cases? > It isn't very easy to write testcase for jasper :( idea: 1) set Policy to Policy.setPolicy(new Policy() { public boolean implies(ProtectionDomain domain, Permission permission) { return true; } public PermissionCollection getPermissions(ProtectionDomain domain) { return Policy.UNSUPPORTED_EMPTY_COLLECTION; } public PermissionCollection getPermissions(CodeSource codesource) { return Policy.UNSUPPORTED_EMPTY_COLLECTION; } }); such policy won't break the vm, since it allows everything. 2) set SecurityManager System.setSecurityManager(new SecurityManager()) 3) instantiate JspRuntimeContext
Without those added permissions, a web application is likely to fail. It may be possible for some applications to operate without these permissions and the failure to add the permission isn't - on its own - sufficient to prevent the application from starting. Therefore, this issue will not be addressed.
It is a shame that this is a WONTFIX as it may stop Jasper working with RMI Java6+ JVM. One needs security for its classloader to work, the other bangs up against a changed semantics of Sun's JVM. It is also hard to see how this can be fixed in Jasper. Here is what the Java6 javadocs have to say on the topic: "Applications are discouraged from calling this method since this operation may not be supported by all policy implementations. Applications should solely rely on the implies method to perform policy checks. If an application absolutely must call a getPermissions method, it should call getPermissions(ProtectionDomain). The default implementation of this method returns Policy.UNSUPPORTED_EMPTY_COLLECTION. This method can be overridden if the policy implementation can return a set of permissions granted to a CodeSource." What would happen if Jasper could recognise the situation in which there was a read-only policy and skip trying to set permissions -or could it perhaps check to see if the permissions were already granted by the security manager before trying to set them? See also http://mail-archives.apache.org/mod_mbox/incubator-river-user/200810.mbox/%3C20081015181649.GB4649@east%3E
Jasper already tries to set the permission, catches the exception it if fails and carries on anyway. What other changes are you looking for?