| Summary: | Permisssions for Hornetq are cached and the cache is not being invalidated under some circumstances | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Filip Nguyen <fnguyen> | ||||
| Component: | JBoss Messaging, Security | Assignee: | Clebert Suconic <clebert.suconic> | ||||
| Status: | ASSIGNED --- | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 5.2.0.ER3 | CC: | clebert.suconic, csuconic, hgao, kevin.conner, ldimaggi, rwagner | ||||
| Target Milestone: | --- | ||||||
| Target Release: | FUTURE | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-3363 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-09-29 22:03:55 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Filip Nguyen
2011-09-07 07:55:52 UTC
Link: Added: This issue is a dependency of JBPAPP-7256 What you want? us to read the file every time? That's not practical... We just cache the setting and wait the deployer to kick in redeployment You will have the old setting until the redeployment happened. you can use the management API to change the setting in real time if you like. So I don't think this is a bug Clebert, I think his point might be that the results of the initial security check may be cached indefinitely because of the assignment to lastCheck. The cached data may never become stale. Steps to Reproduce: Removed: To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed. # deploy, runtest # quickly delete this security settings <permission type="send" roles="gatewayrole"/> # quickly runtest again, now you can runtest how many times you want provided you don't exceed security-invalidation-interval Added: To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed. # deploy, runtest # quickly delete this security settings <permission type="send" roles="gatewayrole"/> # quickly runtest again, now you can runtest how many times you want provided you interval between each message doesn't exceed security-invalidation-interval Ah, I see now how "Steps to reproduce" can be interpreted ambiguously. I am sorry for not being precise enough. As Kevin pointed out the cached data may never become stale. Clebert, you said that "We just cache the setting and wait the deployer to kick in redeployment" is this really true? The behavior I observed was that redeployment *does not* clear the cache. Every time somebody sends message into queue the validity of cache is prolonged. However to answer your question (although it is not relevant what I want because I am not familiar with all business requirements of hornetq) in my opinion the easiest solution may be to just clear the cache with "onChange()" method that you already have in the code base upon redeployment. Hi Filip, Where can I get the said jms_secured example to reproduce this issue? Thanks Howard Hi Yong, jms_secured quickstart is packaged with SOA Platform distribution in <SOA-P>/jboss-as/samples/quickstarts/jms_secured I am attaching the server log from session where I reproduced. Comment on the log follows.
14:39:19,997 deploying the QS. Hornetq config:
{code:title=hornetq-configuration.xml|borderStyle=solid}
<security-settings>
<security-setting match="#">
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="send" roles="guest"/>
</security-setting>
<security-setting match="jms.queue.quickstart_jms_secured_Request_gw">
<permission type="send" roles="esbrole,gatewayrole"/>
<permission type="consume" roles="esbrole"/>
</security-setting>
<security-setting match="jms.queue.quickstart_jms_secured_Request_esb">
<permission type="send" roles="esbrole"/>
<permission type="consume" roles="esbrole"/>
</security-setting>
</security-settings>
{code}
14:39:46,615 runtest
14:40:08,991 deleting line <permission type="send" roles="esbrole"/> from hornetq config and save.
14:40:34,769 runtest:
{noformat}
javax.jms.JMSSecurityException: User: esbuser doesn't have permission='SEND' on address jms.queue.quickstart_jms_secured_Request_esb
{noformat}
Attachment: Added: server.log Hi Filip, Thanks for the info. I have another question, where can I download 5.2.0.ER3? Howard Link: Added: This issue is related to SOA-3423 Howard, I took a look on the code, and it was really simple to fix it... the securityStore wasn't calling the registerListener. It's been fixed now.. thanks for taking a look on this. Can't resolve until we have a fixed jar for SOA HornetQ is technical preview, so should not hold up the 5.2.0 release. HornetQ is a TP for SOA 5.2 and cannot block the releaase. Related to https://issues.jboss.org/browse/JBPAPP-7256. Verified on 5.3 but 5.2 still has this bug so this JIRA remains open. 5.2 is already release.. how can we fix in a previous release? Besides this was fixed as part of an one-off patch.. so this is definitely a close! Ahhh... I'm sorry.... SOA EAP! I confused the 5.2 with EAP... I'm not sure how I could help you. we have fixed on HornetQ. Let me know what I can do. |