[logback-user] SecurityManager issue using logback

[ceki]

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