tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Petrovic" <mspetro...@gmail.com>
Subject A custom profiling security manager, and an anomaly
Date Mon, 06 Nov 2006 00:54:42 GMT
In the course of teaching myself how to write a security manager that
reports to which resources an application wants runtime access, I have run
into something I do not understand.  I struggled with whether to start here
or on a Sun security forum or on the Tomcat dev list.  Given the problem may
well be related to Tomcat 5.5.17 runtime dynamics, which is the environment
in which I am developing this tool, I decided to start here.  If I have come
to an incorrect conclusion in that choice, please accept my apologies in
advance.

A custom security manager might override both forms of
java.lang.SecurityManager.checkPermission().  Mine does.  My difficulty
arises in the Tomcat-runtime behavior of the two-parameter form
java.lang.SecurityManager.checkPermission(Permission p, Object context), to
which I see callbacks at runtime.

During checkPermission(Permission p, Object context), a preliminary goal is
to get at the ProtectionDomains wrapped in the second argument "Object
context".  "context" is of type AccessControlContext, and has no getters
that provide access to the private member array of ProtectionDomains (per
JDK javadoc and source code).  Hence, I use reflection to learn the
ProtectionDomains.

Here is the essence of the implementation of my two-parameter form of
checkPermission():

@Override
public void checkPermission(Permission permission, Object context) {
   try {
      Field[] fields = AccessControlContext.class.getDeclaredFields();
      for(int i=0; i<fields.length; ++i ) {
         if( fields[i].getName().equals("context") ) {
            fields[i].setAccessible(true);
            Object o = fields[i].get(context);
            ProtectionDomain[] pda = (ProtectionDomain[] )o;
            // ...
         }
      }
   }
   catch (...) {}
}
// ...

Swapping in my custom security manager, then starting Tomcat ...

1) When Tomcat starts up and attempts to initialize JmxMBeanServer, the
result is ultimately  this fatal exception in catalina.out

Nov 5, 2006 4:12:38 PM org.apache.catalina.startup.BootstrapinitClassLoaders
SEVERE: Class loader creation threw exception
java.lang.IllegalStateException: Can't register delegate.
        at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(
JmxMBeanServer.java:1226)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java
:222)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java
:171)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(
JmxMBeanServer.java:1395)
        at javax.management.MBeanServerBuilder.newMBeanServer(
MBeanServerBuilder.java:93)
        at javax.management.MBeanServerFactory.newMBeanServer(
MBeanServerFactory.java:316)
        at javax.management.MBeanServerFactory.createMBeanServer(
MBeanServerFactory.java:219)
        at javax.management.MBeanServerFactory.createMBeanServer(
MBeanServerFactory.java:180)
        at org.apache.catalina.startup.Bootstrap.createClassLoader(
Bootstrap.java:188)
        at org.apache.catalina.startup.Bootstrap.initClassLoaders(
Bootstrap.java:97)
        at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:212)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)

2) Now this is quirky if not lame:  If I replace

            Object o = fields[i].get(context);

with

            Object o = fields[i].get(AccessController.getContext());

then Tomcat starts and runs fine.  Granted, there is absolutely no reason
for using the second form of the Field.get(), because it contains a context
in which we have no interest.  But in experimenting, troubleshooting, and
sanity checking, I had to find some way of satisfying type-correctness in
the call to Field.get().  I found the second form "worked", even though it
produces inappropriate output (not shown).

I must be missing something deeply fundamental.  Whatever is failing does
*not* like me trying to inspect "context" during reflection --- or so it
seems.  Reading the source to com.sun.jmx.mbeanserver.JmxMBeanServer sheds
no light I can discern.

Thanks for reading this far.  Can anyone help me understand better what
might be going on here?

-- 
Mark

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message