For those interested, I believe I got this working, although I'm not yet
certain precisely what I did differently that made the difference. Details
of the custom security profiler are here
http://www.petrovic.org/content/SecMgrTutorial/sm.html .
On 11/5/06, Mark Petrovic <[EMAIL PROTECTED]> wrote:
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
--
Mark
