[logback-user] SecurityManager issue using logback

ceki ceki at qos.ch
Sun Nov 6 19:07:36 CET 2011

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
 > even per thread), for example if a different SecurityManager is
 > installed.

One rarely installs a different SecurityManager but in general you are

> 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

> Joern.


More information about the Logback-user mailing list