Uploaded image for project: 'JBoss Enterprise SOA Platform'
  1. JBoss Enterprise SOA Platform
  2. SOA-3363

Permisssions for Hornetq are cached and the cache is not being invalidated under some circumstances

    XMLWordPrintable

Details

    • Hide

      To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed.

      1. deploy, runtest
      2. quickly delete this security settings <permission type="send" roles="gatewayrole"/>
      3. quickly runtest again, now you can runtest how many times you want provided you interval between each message doesn't exceed security-invalidation-interval
      Show
      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

    Description

      When using Hornetq and it's security-settings (configured in hornetq-configuration.xml - but I suspect this issue occurs also with Management API) the security settings are being cached in SecurityStoreImpl.java (HashMap cache). After modifying hornetq-configuration.xml when server redeploy takes place but the cache doesn't invalidate (I thing method public onChange() is there for that reason but never get called). The worst thing is that cache is being "marked as valid" as long as security settings are checked (SecurityStoreImpl:242 -> lastCheck = now and that happens all the time (whenever anybody accesses any queue!). Implicit value for security-invalidation-interval seems to be 10 seconds.

      Following can happen because of described implementation:

      1. QueueA gets deployed and admin sets permission SEND permission for RoleX
      2. RoleX sends into the QueueA (thus makes cache valid for at least security-invalidation-interval)
      3. Permission SEND is deleted from hornetq-configuration.xml and security settings are automatically redeployed
      4. RoleX happens to send into QueueA before cache invalidates
      5. RoleX sends as many messages int QueueA as he wants.

      I think this is an integration issue becase cache is not being invalidated upon settings redeploy.

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. JBPAPP-7256 Permisssions for Hornetq are cached and the cache is not being invalidated under some circumstances

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed
          is related to

          Bug - A problem which impairs or prevents the functions of the product. SOA-3423 Deletion of whole security-setting element from honetq-configuration.xml have no effect

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              csuconic@redhat.com Clebert Suconic
              fnguyen_jira Filip Nguyen (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: