Topic
  • 6 replies
  • Latest Post - ‏2011-04-02T01:16:17Z by tzhao
tzhao
tzhao
15 Posts

Pinned topic Custom JACC policy causes statck overflow in WebSphere v8

‏2011-03-31T18:21:39Z |
We have own Policy implementation for JACC provider. This code works for WebSphere 7.0, but it failed on WebSphere 8.0 Beta.

The stacktrace from ffdc file shows that it runs into an infinite loop.
Here is code from ASBPolicy.java:126:
rslt = config.implies(globalPolicy, PolicyContext.getContextID(), pd, permission);

I noticed the PolicyContext is from WebSphere\AppServer\plugins\javax.j2ee.jacc.jar.

The ffdc file is attached.

Thanks!
Updated on 2011-04-02T01:16:17Z at 2011-04-02T01:16:17Z by tzhao
  • kark
    kark
    18 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-03-31T21:28:38Z  
    Hi,

    Sorry for the issues you are seeing. We have not seen this issue with our own JACC implementation so has to be specific with your implementation.

    Based on the stack trce it looks like a Java 2 permission check is being performed for the System.getProperty method which is calling your JACC implementation's checkAccess method which seemed to load a class which also triggers a Java 2 permission check that will again call your checkAccess method causing the stack overflow. Can you confirm that you are not doing anything different with respect to Java 2 security in the Beta version?

    I will investigate what has changed in this area that is triggering the Java 2 security check in Beta.

    However, typically your policy implementation should be delegating all non-JACC permissions to the default policy object that was set prior to your JACC's provider being initialized. This way your JACC implementation can only handle the JACC permissions and leave it to the default policy to handle all other permission. If that is done, in this scenario, WebSphere will handle both these permission checks and would not go through your checkAccess method which should avoid this stack overflow.

    --Ajay Reddy
  • tzhao
    tzhao
    15 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-04-01T00:36:37Z  
    • kark
    • ‏2011-03-31T21:28:38Z
    Hi,

    Sorry for the issues you are seeing. We have not seen this issue with our own JACC implementation so has to be specific with your implementation.

    Based on the stack trce it looks like a Java 2 permission check is being performed for the System.getProperty method which is calling your JACC implementation's checkAccess method which seemed to load a class which also triggers a Java 2 permission check that will again call your checkAccess method causing the stack overflow. Can you confirm that you are not doing anything different with respect to Java 2 security in the Beta version?

    I will investigate what has changed in this area that is triggering the Java 2 security check in Beta.

    However, typically your policy implementation should be delegating all non-JACC permissions to the default policy object that was set prior to your JACC's provider being initialized. This way your JACC implementation can only handle the JACC permissions and leave it to the default policy to handle all other permission. If that is done, in this scenario, WebSphere will handle both these permission checks and would not go through your checkAccess method which should avoid this stack overflow.

    --Ajay Reddy
    Hi Ajay,

    Thanks for looking at it.

    The java2 security should be disabled. I attached the security.xml here for your reference.

    Thanks!
  • kark
    kark
    18 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-04-01T20:51:02Z  
    • tzhao
    • ‏2011-04-01T00:36:37Z
    Hi Ajay,

    Thanks for looking at it.

    The java2 security should be disabled. I attached the security.xml here for your reference.

    Thanks!
    Hi,

    Can you tell us what your implies method is trying to load here? It is possible that this class might have been loaded by some other code earlier during bringup in 7.0 and in 8.0 beta it is not being loaded anymore until the implies method is called. We have seen similar issue in one of our scenarios and we fixed it by loading the class in our code before the implies is called.

    --Ajay Reddy
  • tzhao
    tzhao
    15 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-04-01T21:15:36Z  
    • kark
    • ‏2011-04-01T20:51:02Z
    Hi,

    Can you tell us what your implies method is trying to load here? It is possible that this class might have been loaded by some other code earlier during bringup in 7.0 and in 8.0 beta it is not being loaded anymore until the implies method is called. We have seen similar issue in one of our scenarios and we fixed it by loading the class in our code before the implies is called.

    --Ajay Reddy
    Hi Ajay,

    The stack trace shows that the issue happened before our "real" JACC logic is called.

    I think the issue is more likely caused by that JACC is invoked when PolicyContext class is loaded. I am wondering why it is called given the java2 security is disabled.

    Here is the method of implies, and I marked the line of problem in bold.
    public boolean implies(ProtectionDomain pd, Permission permission)
    {
    if (logger.isLoggable(Level.FINER)) {
    logger.entering(this.getClass().getName(), "implies",
    new Object[]{pd, permission});
    }
    boolean rslt = false;

    Config config = getConfig();
    if (config == null) {
    rslt = globalPolicy.implies(pd, permission);
    } else {
    rslt = config.implies(globalPolicy, PolicyContext.getContextID(), pd, permission);
    }

    if (logger.isLoggable(Level.FINER)) {
    logger.exiting(this.getClass().getName(), "implies", new Boolean(rslt));
    }
    return rslt;
    }

    Thanks!
  • kark
    kark
    18 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-04-01T22:34:59Z  
    • tzhao
    • ‏2011-04-01T21:15:36Z
    Hi Ajay,

    The stack trace shows that the issue happened before our "real" JACC logic is called.

    I think the issue is more likely caused by that JACC is invoked when PolicyContext class is loaded. I am wondering why it is called given the java2 security is disabled.

    Here is the method of implies, and I marked the line of problem in bold.
    public boolean implies(ProtectionDomain pd, Permission permission)
    {
    if (logger.isLoggable(Level.FINER)) {
    logger.entering(this.getClass().getName(), "implies",
    new Object[]{pd, permission});
    }
    boolean rslt = false;

    Config config = getConfig();
    if (config == null) {
    rslt = globalPolicy.implies(pd, permission);
    } else {
    rslt = config.implies(globalPolicy, PolicyContext.getContextID(), pd, permission);
    }

    if (logger.isLoggable(Level.FINER)) {
    logger.exiting(this.getClass().getName(), "implies", new Boolean(rslt));
    }
    return rslt;
    }

    Thanks!
    Hi,

    As the stack trace shows, the security manager that is being used is java.lang.SecurityManager which should be the default JDK's security manager - so no WebSphere's security manager is involved.

    We will confirm the behavior with the JDK team to make sure if that is the expected behavior and/or if it has changed recently.

    However, based on the scenario that we have seen here it might be possible that the only thing that might have changed here is the way this PolicyContext (assuming that this is the class that is being loaded) is being loaded now. In the 7.0 version, this class might have been loaded prior to this method call in which case it will not go through the process of loading it again and thus avoiding the security permission check.

    --Ajay
  • tzhao
    tzhao
    15 Posts

    Re: Custom JACC policy causes statck overflow in WebSphere v8

    ‏2011-04-02T01:16:17Z  
    • kark
    • ‏2011-04-01T22:34:59Z
    Hi,

    As the stack trace shows, the security manager that is being used is java.lang.SecurityManager which should be the default JDK's security manager - so no WebSphere's security manager is involved.

    We will confirm the behavior with the JDK team to make sure if that is the expected behavior and/or if it has changed recently.

    However, based on the scenario that we have seen here it might be possible that the only thing that might have changed here is the way this PolicyContext (assuming that this is the class that is being loaded) is being loaded now. In the 7.0 version, this class might have been loaded prior to this method call in which case it will not go through the process of loading it again and thus avoiding the security permission check.

    --Ajay
    I attached the classloader verbose from WebSphere v7. It shows the PolicyContext is loaded after ASBPolicy and ASBPolicy$Config, but I am not if it is loaded before the implies method is called.