Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 955674

Summary: ACL delete action should not ignore object's properties other than name
Product: Red Hat Enterprise MRG Reporter: Pavel Moravec <pmoravec>
Component: qpid-cppAssignee: Chuck Rolke <crolke>
Status: CLOSED ERRATA QA Contact: Zdenek Kraus <zkraus>
Severity: high Docs Contact:
Priority: high    
Version: 2.3CC: ctrianta, jross, lzhaldyb, mtoth, rrajaram, sauchter, zkraus
Target Milestone: 3.0Keywords: Improvement, Patch, TestCaseProvided
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: qpid-cpp-0.22-4.el6, qpid-cpp-0.22-4.el5 Doc Type: Enhancement
Doc Text:
Users can now further restrict ACL rules with respect to the queues and exchanges they are allowed to delete. It is now possible to allow or deny access to deleting queues and exchanges based on durability and other settings. Restricting queue and exchange deletion prevents users from interfering with each other in a broker.
Story Points: ---
Clone Of:
: 957869 (view as bug list) Environment:
Last Closed: 2014-09-24 15:07:46 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 957869    
Attachments:
Description Flags
Patch proposal crolke: review+

Description Pavel Moravec 2013-04-23 14:03:25 UTC
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.

Comment 2 Pavel Moravec 2013-04-24 14:15:28 UTC
Created attachment 739469 [details]
Patch proposal

Following ACT_CREATE authorize call in Broker.cpp, ACT_DELETE authorize call updated accordingly.

Smoke testing run fine.

Comment 3 Pavel Moravec 2013-04-25 07:13:21 UTC
QPID-4775 created for the same.

Comment 5 Chuck Rolke 2013-05-02 15:47:50 UTC
Fixed upstream in trunk at commit 1478418.

The upstream patch does not include the MAX-SIZE properties in the paramaeter list for queue deletion.

Comment 7 Christos Triantafyllidis 2013-05-06 07:18:57 UTC
Ignore my last comment. It should have been to the 957869 bug report.

Christos

Comment 8 Zdenek Kraus 2013-06-18 11:04:31 UTC
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

Comment 9 Chuck Rolke 2013-06-26 17:51:45 UTC
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.

Comment 10 Zdenek Kraus 2013-06-27 09:06:50 UTC
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 11 Chuck Rolke 2014-06-23 14:02:00 UTC
Comment on attachment 739469 [details]
Patch proposal

This bug is VERIFIED

Comment 13 errata-xmlrpc 2014-09-24 15:07:46 UTC
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