[
https://issues.apache.org/jira/browse/GERONIMO-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527639
]
Vamsavardhana Reddy commented on GERONIMO-1053:
-----------------------------------------------
Can someone verify if this is still a problem? Posting a testcase would be
helpful if this is still a problem.
> Session Bean, Finder, & Method Permissions
> ------------------------------------------
>
> Key: GERONIMO-1053
> URL: https://issues.apache.org/jira/browse/GERONIMO-1053
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenEJB, security
> Affects Versions: 1.0-M5
> Reporter: Aaron Mulder
> Priority: Blocker
>
> I have an EAR with a Web App, Session Bean, and CMP Entity Bean, using the M5
> release.
> The user brings up a secure page on the web app and logs in.
> The web code invoked after the login calls the session bean.
> The session bean calls a finder on the entity bean, and gets this (in the
> session bean method code, where it calls the finder):
> {noformat}
> Caused by: javax.ejb.TransactionRolledbackLocalException
> at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:123)
> at
> org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
> at
> org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
> at
> org.openejb.GenericEJBContainer$DefaultSubjectInterceptor.invoke(GenericEJBContainer.java:545)
> at
> org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
> at
> org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129)
> at
> org.openejb.proxy.EntityEJBLocalHome$$EnhancerByCGLIB$$afb1a239.findAll(<generated>)
> at
> org.loadmagus.ejb.TestManagerBean.getAllApplications(TestManagerBean.java:70)
> ... 48 more
> Caused by: javax.ejb.AccessLocalException: access denied
> (javax.security.jacc.EJBMethodPermission EntityBean findAll,LocalHome,)
> at
> org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:107)
> at
> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56)
> at
> org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81)
> at
> org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136)
> at
> org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:84)
> at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119)
> ... 55 more
> {noformat}
> The ejb-jar.xml for the EJBs in question has:
> {noformat}
> <security-role>
> <role-name>Developer</role-name>
> </security-role>
> <method-permission>
> <role-name>Developer</role-name>
> <method>
> <ejb-name>SessionBean</ejb-name>
> <method-name>*</method-name>
> </method>
> </method-permission>
> <method-permission>
> <role-name>Developer</role-name>
> <method>
> <ejb-name>EntityBean</ejb-name>
> <method-name>*</method-name>
> </method>
> </method-permission>
> {noformat}
> So it's a little odd that the session bean sees a transaction rolled back
> exception rather than the real security exception, but whatever.
> The real problem is that both the session bean and the entity bean are
> covered by identical all-inclusive method permission blocks, so if the user
> got into the session bean, there should be no reason they can't get into the
> entity bean. The syntax above is specifically supported in the
> ejb-jar-2_1.xsd Schema (#1; "This style is used to refer to all the methods
> of the specified enterprise bean's home, component, and/or web service
> endpoint interfaces.")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
