Red Hat Bugzilla – Bug 955674
ACL delete action should not ignore object's properties other than name
Last modified: 2014-10-14 10:18:10 EDT
Description of problem: ACL rule like: acl allow all delete queue autodelete=true should allow deletion of autodelete queues _only_. While any queue can be deleted. The same applies to any object's property other than queue's name (see Broker::deleteQueue method and how acl->authorise is called). The same applies not only to queues but also to exchanges. Version-Release number of selected component (if applicable): 0.18-14 How reproducible: 100% Steps to Reproduce: 1. cat <acl-file> # simply allow all except for deleting non-durable queue acl allow-log all consume all acl allow-log all publish all acl allow-log all create all acl allow-log all access all acl allow-log all bind all acl allow-log all unbind all acl allow-log all purge all acl allow-log all update all acl allow-log all delete exchange acl allow-log all delete queue durable=true acl deny-log all all 2. Start broker with auth=yes and the ACL file 3. qpid-config -b admin/admin@localhost:5672 add queue TransientQueue 4. qpid-config -b admin/admin@localhost:5672 del queue TransientQueue Actual results: Steps 3 and 4 pass. Expected results: Deleting queue should fail, as the queue is not durable. In fact, even _creating_ the queue that way should raise an exception, as deleting auxiliary queue named like "4135cd9e-04b8-4cef-bcd0-5404444d7a04:0.0" (where the qpid-config gets response) should fail. Additional info: Same scenarios are applicable for all other queue properties and/or exchange properties. Just queue/exchange name is checked.
Created attachment 739469 [details] Patch proposal Following ACT_CREATE authorize call in Broker.cpp, ACT_DELETE authorize call updated accordingly. Smoke testing run fine.
QPID-4775 created for the same.
Fixed upstream in trunk at commit 1478418. The upstream patch does not include the MAX-SIZE properties in the paramaeter list for queue deletion.
Ignore my last comment. It should have been to the 957869 bug report. Christos
I've discovered a problem with this patch. The ACL module wrongly get a 'reject' policy type instead of 'ring-strict' thus fails to evaluate rules correctly. ## ACL file: acl allow root@QPID all all acl allow guest@QPID all all acl allow-log all consume all acl allow-log all publish all acl allow-log all create all acl allow-log all access all acl allow-log all bind all acl allow-log all unbind all acl allow-log all purge all acl allow-log all update all acl allow dela@QPID delete queue policytype=reject acl allow delb@QPID delete queue policytype=ring_strict acl deny all all ## actions for X in reject ring-strict; do ./qc2_drain.py -b root/root@localhost:5672 "$X;{create:always,node:{type:queue,x-declare:{arguments:{'qpid.policy_type':$X}}}}"; done ./qc2_drain.py -b dela/dela@localhost:5672 "reject; { delete: always }" ./qc2_drain.py -b delb/delb@localhost:5672 "ring-strict; { delete: always }" qpid.messaging.exceptions.UnauthorizedAccess: unauthorized-access: ACL denied queue delete request from delc@QPID (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/Broker.cpp:1336)(403) ## broker log 2013-06-18 13:01:46 [Security] debug ACL: Lookup for id:dela@QPID action:delete objectType:queue name:reject with params { durable=false autodelete=false exclusive=false alternate= policytype=reject } 2013-06-18 13:01:46 [Security] debug ACL: checking rule [rule 11 ruleMode = allow props{ policytype=reject }] 2013-06-18 13:01:46 [Security] debug ACL: the pair(policytype,reject) given in lookup matched the pair(policytype,reject) given in the rule 2013-06-18 13:01:46 [Security] debug ACL: Successful match, the decision is:allow < ... > 2013-06-18 13:01:54 [Security] debug ACL: Lookup for id:delb@QPID action:delete objectType:queue name:ring-strict with params { durable=false autodelete=false exclusive=false alternate= policytype=reject } 2013-06-18 13:01:54 [Security] debug ACL: checking rule [rule 12 ruleMode = allow props{ policytype=ring_strict }] 2013-06-18 13:01:54 [Security] debug ACL: the pair(policytype,reject) given in lookup doesn't match the pair(policytype,ring_strict) given in the rule 2013-06-18 13:01:54 [Security] debug ACL: No successful match, defaulting to the decision mode deny
In current trunk --limit-policy values of flow_to_disk and ring_strict are not recognized. From qpid-config I can do: > qpid-config add queue x-reject --limit-policy=reject > qpid-config add queue x-ftd --limit-policy=flow-to-disk > qpid-config add queue x-ring --limit-policy=ring > qpid-config add queue x-ring-s --limit-policy=ring-strict And things look great. Over at the broker console, however: 2013-06-26 13:36:39 [Broker] notice Broker running 2013-06-26 13:38:07 [Broker] warning Unrecognised policy option: flow_to_disk 2013-06-26 13:38:52 [Broker] warning Unrecognised policy option: ring_strict So there are several issues going on here. 1. qpid-config is allowing users to specify bogus policy settings 2. bogus policy settings are not flagged with an error - just a log warning 3. the broker ignores the bogus policy settings and proceeds as if the user had specified none. 4. the ACL code in question checks for "ring" or "reject" which are the only allowable settings. The --limit-policy changed a lot during the upstream 0.18 - 0.20 transition.
Okay, the rest of policies and ACL limits works okay. For flow-to-disk and ring-strict I've created a separated bugs (Bug 978867, Bug 978868). Thus I can move this bug to VERIFIED, as we cleared out all misunderstandings. It was tested on RHEL 5.9 and 6.4, i386 and x86_64, with packages: qpid-tools-0.22-2 qpid-cpp-client-0.22-5 qpid-qmf-0.22-4 qpid-cpp-server-devel-0.22-5 python-qpid-qmf-0.22-4 python-qpid-0.22-2 qpid-proton-c-0.4-2.2 qpid-cpp-client-devel-docs-0.22-5 qpid-cpp-server-0.22-5 qpid-cpp-client-rdma-0.22-5 qpid-cpp-client-devel-0.22-5 qpid-cpp-server-ssl-0.22-5 qpid-cpp-server-store-0.22-5 qpid-cpp-server-ha-0.22-5 qpid-cpp-client-ssl-0.22-5 qpid-cpp-server-rdma-0.22-5 qpid-cpp-server-xml-0.22-5
Comment on attachment 739469 [details] Patch proposal This bug is VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1296.html