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/AccessController.html
> 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
_______________________________________________
Logback-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-user
