activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue
Date Thu, 24 May 2018 13:17:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488966#comment-16488966
] 

ASF subversion and git services commented on ARTEMIS-1872:
----------------------------------------------------------

Commit 659d23cb28ce4299be5826ed1b6113458c6d0a1a in activemq-artemis's branch refs/heads/master
from [~michael.andre.pearce]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=659d23c ]

ARTEMIS-1872 Fixing address security checks 

Ensure CREATE_ADDRESS is honored and behavior is consistent across protocols.  

> 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)

Mime
View raw message