[ https://issues.apache.org/jira/browse/ARTEMIS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16481316#comment-16481316 ]
ASF GitHub Bot commented on ARTEMIS-1872: ----------------------------------------- Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2093 @michaelandrepearce it looks fine to me: probably I would have performed the check about the queue existence just for the durable ones > Correctly check for queue exists before creating shared queue > ------------------------------------------------------------- > > Key: ARTEMIS-1872 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1872 > Project: ActiveMQ Artemis > Issue Type: Bug > Affects Versions: 2.5.0 > Reporter: Michael Andre Pearce > Priority: Major > > Prior to 2.5.0, artemis incorrectly always checked the perms for Non Durable > on createSharedQueue , even if the queue being created was a Durable queue. > securityCheck(address, name, CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*); > > In 2.5.0+ this has been corrected, so it checks the permissions appropriately > for the durability. > securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* : > CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*); > > This though has exposed that in some area's of the Core client code, and also > AMQP, and OpenWire that the code isn't checking that queue exists before > calling to create it, meaning a client with consume permission but without > create durable queue permissions, would fail but should not as the queue > exists. > Also it was noted on creating the test case to prove this that AMQP JMS > Client when security exception occurs, was not correctly throwing > JMSSecurityException, this is due to the broker not returning the correct > AMQP error code, in these circumstances. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)