Bug 39480

Summary: calling getContextClassLoader without doPriv
Product: Taglibs Reporter: s.kenna <kenna>
Component: Standard TaglibAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P1    
Version: 1.2.0   
Target Milestone: ---   
Hardware: All   
OS: All   

Description s.kenna 2006-05-03 20:33:26 UTC
Getting the following exception when running JSTL in the webcontainer runtime
with security turned on:
java.security.AccessControlException: Access denied (java.lang.RuntimePermission
getClassLoader)
	at java.security.AccessController.checkPermission(AccessController.java:104)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
	at
com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189)
	at java.lang.Thread.getContextClassLoader(Thread.java:484)
	at org.apache.taglibs.standard.tag.common.fmt.BundleSupport.findMatch(Unknown
Source)

According to http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html,
the following restrictions are applied:
If the caller's class loader is null, or is the same as or an ancestor of the
context class loader for the thread whose context class loader is being
requested, no permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.

In the org.apache.taglibs.standard.tag.common.fmt.BundleSupport.findMatch, among
other areas, JSTL is calling Thread.currentThread().getContextClassLoader());
Since JSTL is now a part of the JEE5 runtime and not a jar added to an
application, these calls to the classloader need to be wrappered with a doPriv
block.
Comment 1 Henri Yandell 2006-12-27 14:20:05 UTC
I see three locations that call getContextClassLoader():

src/org/apache/taglibs/standard/tag/common/fmt/BundleSupport.java (twice)
src/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java

While JSTL is a part of JEE5; we currently don't have any strong plans for a 1.2
compliant release, so effort is on a version of the 1.1 spec with bugfixes. So
you should still be adding a jar to the runtime. If the JEE5 one is the only
scenario for this bug, then it's probably best reported to the Glassfish
implementation. 

https://glassfish.dev.java.net/
Comment 2 Henri Yandell 2009-05-25 02:34:37 UTC
Now fixed.