You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org> on 2005/10/10 07:55:47 UTC
[jira] Created: (GERONIMO-1053) Session Bean, Finder, & Method Permissions
Session Bean, Finder, & Method Permissions
------------------------------------------
Key: GERONIMO-1053
URL: http://issues.apache.org/jira/browse/GERONIMO-1053
Project: Geronimo
Type: Bug
Components: OpenEJB, security
Versions: 1.0-M5
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.0
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):
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
The ejb-jar.xml for the EJBs in question has:
<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>
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1053) Session Bean, Finder, & Method
Permissions
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1053?page=all ]
Aaron Mulder updated GERONIMO-1053:
-----------------------------------
Fix Version/s: 1.1.2
(was: 1.2)
Description:
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.")
was:
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):
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
The ejb-jar.xml for the EJBs in question has:
<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>
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.")
Priority: Blocker (was: Critical)
No idea whether this is still a problem but we better check!
> Session Bean, Finder, & Method Permissions
> ------------------------------------------
>
> Key: GERONIMO-1053
> URL: http://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
> Fix For: 1.1.2
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1053) Session Bean, Finder, & Method
Permissions
Posted by "Viacheslav Grinevich (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1053?page=comments#action_12437515 ]
Viacheslav Grinevich commented on GERONIMO-1053:
------------------------------------------------
I waiting for a resolution yet!
> Session Bean, Finder, & Method Permissions
> ------------------------------------------
>
> Key: GERONIMO-1053
> URL: http://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
> Fix For: 1.1.2
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1053) Session Bean, Finder, & Method
Permissions
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donald Woods updated GERONIMO-1053:
-----------------------------------
Fix Version/s: (was: 1.1.2)
> 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.
[jira] Closed: (GERONIMO-1053) Session Bean, Finder, & Method
Permissions
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks closed GERONIMO-1053.
----------------------------------
Resolution: Fixed
I don't think we would have passed the tck if this was a problem. The code involved is completely different from that in 1.0-M5 and no one has complained recently.
> 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.
[jira] Commented: (GERONIMO-1053) Session Bean, Finder, & Method
Permissions
Posted by "Vamsavardhana Reddy (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (GERONIMO-1053) Session Bean, Finder, & Method Permissions
Posted by "Matt Hogstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1053?page=all ]
Matt Hogstrom updated GERONIMO-1053:
------------------------------------
Fix Version: 1.1
(was: 1.0)
Moved to 1.1
> Session Bean, Finder, & Method Permissions
> ------------------------------------------
>
> Key: GERONIMO-1053
> URL: http://issues.apache.org/jira/browse/GERONIMO-1053
> Project: Geronimo
> Type: Bug
> Components: OpenEJB, security
> Versions: 1.0-M5
> Reporter: Aaron Mulder
> Priority: Critical
> Fix For: 1.1
>
> 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):
> 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
> The ejb-jar.xml for the EJBs in question has:
> <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>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1053) Session Bean, Finder, & Method Permissions
Posted by "Matt Hogstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1053?page=comments#action_12357870 ]
Matt Hogstrom commented on GERONIMO-1053:
-----------------------------------------
Need a read on whether this will get fixed for 1.0 or not. I suspect that most folks aren't using permissions but does this JIRA imply that permissions are broken as a whole ?
> Session Bean, Finder, & Method Permissions
> ------------------------------------------
>
> Key: GERONIMO-1053
> URL: http://issues.apache.org/jira/browse/GERONIMO-1053
> Project: Geronimo
> Type: Bug
> Components: OpenEJB, security
> Versions: 1.0-M5
> Reporter: Aaron Mulder
> Priority: Critical
> Fix For: 1.0
>
> 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):
> 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
> The ejb-jar.xml for the EJBs in question has:
> <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>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira