On 11/6/2011 1:32 AM, Joern Huxhorn wrote:
There is one issue with the code in http://goo.gl/zASBm, though:
It checks for getClassLoader permission in a static code block only, i.e. when the class is initially loaded by the classloader, and saves that information for later reference.
The reference is never used anywhere getClassLoaderAsPrivileged method is never invoked by logback. The privileged block is result of a compromise: http://jira.qos.ch/browse/LBCLASSIC-263
I don't think that this is a valid optimization for precisely the reason that this permission can change during runtime (according to
http://download.oracle.com/javase/1.4.2/docs/api/java/security/AccessControl...
even per thread), for example if a different SecurityManager is installed.
One rarely installs a different SecurityManager but in general you are right.
The method using the statically initialized boolean should probably look like this instead:
public static ClassLoader getClassLoaderAsPrivileged(final Class clazz) { try { AccessController.checkPermission(new RuntimePermission("getClassLoader")); return AccessController.doPrivileged( new PrivilegedAction<ClassLoader>() { public ClassLoader run() { return clazz.getClassLoader(); } }); } catch (AccessControlException e) { return null; } }
Not sure if this would solve the problem at hand...
It'll probably make the SecurityException in LBCLASSIC-303 go away by virtue of call reordering. However, it does not explain why invoking AccessController.doPrivileged changes the behavior of RMISecurityManger.
Joern.
-- Ceki http://twitter.com/#!/ceki