1 Reply Latest reply on May 25, 2007 2:47 PM by Daniel Boggs

    ejbStore Running with Incorrect Security Identity

    Daniel Boggs Newbie

      I've got a situation where I'm calling a finder method on an EJB (BeanA) and it is resulting in a call to ejbStore on another bean (BeanB) that was previously modified in the same transaction. The BeanB ejbStore makes a call into yet another bean (BeanC). Beans A, B, and C all run in the same transaction, but BeanA is configured to run-as Role1 and Beans B and C as Role2. BeanC is configured to only allow calls by Role2. (Also, Beans B and C are in a different EAR than BeanA).

      The problem is that the call to ejbStore in BeanB actually still has the security context of BeanA (Role1) instead of running as Role2. So the call into BeanC results in an error, something like "Insufficient method permissions, runAsRole=Role1, method=myMethod, interface=LOCAL, requiredRoles=[Role2]".

      I searched the JBoss source code (using JBoss 3.2.5) and saw that the finder call ends up executing org.jboss.ejb.EntityContainer.synchronizeEntitiesWithinTransaction but never seems to set the appropriate run-as identity when calling ejbStore on the entities it is synchronizing.

      I saw a seemingly related post on this at http://jira.jboss.com/jira/browse/JBAS-4304 but it didn't seem to talk about this security aspect. I could possibly work around the issue using sync-on-commit-only (might not be a good option for us) or by attempting to make the finder call before making modifications in BeanB.

      Is this issue addressed in a later release of the product? We have not really been able to upgrade recently, so my main question is: if this is truly an issue, does it only affect these ejbStore calls for finders, or is there anything else it would effect?

      Thanks for your insight.

      (Using JBoss 3.2.5 on Windows XP, Sun JDK 1.4.2_13)

      Daniel

        • 1. Re: ejbStore Running with Incorrect Security Identity
          Daniel Boggs Newbie

          I partially worked around this issue by making an arbitrary finder call (within the appropriate run-as context) after updating BeanB, so that BeanB's ejbStore is called with the correct run-as context.

          The remaining issue is basically a potential security hole. Say you deploy two EAR files in a JBoss instance. It might be possible, using the invalid run-as security context within an ejbStore call, for the software in one archive to call software in the other archive that it shouldn't be able to call (as long as it's all in the same transaction).

          I suppose one workaround would then be to not let a transaction span two different beans that didn't completely trust each other. Of course the sacrifice there might be data consistency in the application.

          Daniel