Bug 689408

Summary: ACL denials while replicating exclusive queues to a newly joined node
Product: Red Hat Enterprise MRG Reporter: Siddhesh Poyarekar <spoyarek>
Component: qpid-cppAssignee: Alan Conway <aconway>
Status: CLOSED ERRATA QA Contact: Zdenek Kraus <zkraus>
Severity: high Docs Contact:
Priority: high    
Version: 1.3CC: aconway, freznice, iboverma, jross, mcressma, mnewsome, pematous, pmoravec, ppecka, rdassen, rrajaram, zkraus
Target Milestone: 2.2   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: qpid-cpp-0.14-20 Doc Type: Bug Fix
Doc Text:
Cause: During an update, ACL rules were preventing access to the cluster-update exchange. Consequence: new brokers could not join the cluster. Fix: for catch-up connections, which are authenticated as the cluster-user, allow all access to update state. Result: Brokers can join the cluster as expected.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-19 17:19:59 UTC Type: ---
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: 785156, 809460    

Description Siddhesh Poyarekar 2011-03-21 12:16:36 UTC
Description of problem:

Consider the following scenario:

A user 'acluser' has access to:
* create queues with name user.foo.*
* bind to the exchange user.exchanges

When one creates a receiver that logs in as acluser and creates an exclusive queue, any node that joins the existing broker in the cluster (and using the same acl file) will not be able to replicate the exclusive queue.

The cluster-username is defined such that it has all privileges and is hence not limited by ACL.

Version-Release number of selected component (if applicable):
qpid-cpp-server-0.7.946106-28.el5

How reproducible:
Always

Steps to Reproduce:
1. Create ACL for a user as above
2. Create exchange user.exchanges
3. Create exclusive queue user.foo.me as acluser
4. Start the second broker
  
Actual results:
Second broker fails to start. following error is seen in the logs:

Feb 11 20:00:26 dell-pe1950-2 qpidd[1028]: 2011-02-11 20:00:26 info ACL Deny id:acluser@QPID action:bind ObjectType:exchange Name:qpid.cluster-update
Feb 11 20:00:26 dell-pe1950-2 qpidd[1028]: 2011-02-11 20:00:26 error Execution exception: unauthorized-access: ACL denied exchange bind request from acluser@QPID (qpid/broker/SessionAdapter.cpp:182)

Expected results:

Replication should succeed.

Additional info:

It looks like the update for session scope objects like exclusive queues are being done with the session owning user and not with the cluster-username. This seems to be the problem, since the session owning user in this case does not have the right privileges to bind to qpid.cluster-update.

One could simply write an ACL rule allowing all users access to qpid.cluster-update but that may not be the best way to fix this since only the replication process should have this kind of access.

Comment 4 Alan Conway 2011-10-12 18:00:59 UTC
Fixed on trunk: r1182451 | QPID-3544: ACL denials while replicating exclusive queues to a newly joined node.

Comment 5 Alan Conway 2011-10-12 18:24:02 UTC
Note: fix on trunk was incomplete, also need this commit:

r1182451 | QPID-3544: ACL denials while replicating exclusive queues to a newly joined node

Comment 6 Alan Conway 2011-10-12 18:33:21 UTC
Typo in comment 5, the additional commit is:r1182514

Comment 8 Pavel Moravec 2012-06-13 14:48:48 UTC
*** Bug 809460 has been marked as a duplicate of this bug. ***

Comment 10 Zdenek Kraus 2012-07-27 12:35:54 UTC
Testing Packages:
python-qpid-0.14-7.el5
python-qpid-qmf-0.14-12.el5
qpid-cpp-client-0.14-19.el5
qpid-cpp-client-devel-0.14-19.el5
qpid-cpp-client-devel-docs-0.14-19.el5
qpid-cpp-client-ssl-0.14-19.el5
qpid-cpp-mrg-debuginfo-0.14-18.el5
qpid-cpp-server-0.14-19.el5
qpid-cpp-server-cluster-0.14-19.el5
qpid-cpp-server-devel-0.14-19.el5
qpid-cpp-server-ssl-0.14-19.el5
qpid-cpp-server-store-0.14-19.el5
qpid-cpp-server-xml-0.14-19.el5
qpid-qmf-0.14-12.el5
qpid-qmf-devel-0.14-12.el5
qpid-tools-0.14-3.el5

python-qpid-0.14-8.el6
python-qpid-qmf-0.14-12.el6_3
qpid-cpp-client-0.14-19.el6_3
qpid-cpp-client-devel-0.14-19.el6_3
qpid-cpp-client-devel-docs-0.14-19.el6_3
qpid-cpp-server-0.14-19.el6_3
qpid-cpp-server-cluster-0.14-19.el6_3
qpid-cpp-server-devel-0.14-19.el6_3
qpid-cpp-server-store-0.14-19.el6_3
qpid-cpp-server-xml-0.14-19.el6_3
qpid-qmf-0.14-12.el6_3
qpid-tools-0.14-4.el6_3

Tested on RHEL 5.8, RHEL 6.3 && i386, x86_64

We discovered slight problem with fix in 0.14-19:

Replication of exclusive Queue is no more denied by ACL, but Queue is replicated as NON-Exclusive, that is incorrect. -> ASSIGNED

Comment 11 Alan Conway 2012-07-27 15:53:21 UTC
Not sure why this isn't working but it should not be hard to fix. Please describe how you reproduce the problem, or attach a test case if you have one.

Comment 12 Zdenek Kraus 2012-07-30 06:09:05 UTC
1/ Prepare cluster without authentication, without ACL.
2/ Start node A.
3/ create exclusive Q by python spout:
# ./spout -b user/user@<node_A:port_A> "exclQ.A; {create: sender, delete: receiver, node:{ x-declare:{ auto-delete: false, exclusive: true } } }" "$(date | md5sum)"
4/ Start node B, cluster joining
5/ check created Q is not exclusive on node B

NOTE: authentication has no influence on behaviour in this case.

Comment 13 Alan Conway 2012-07-31 20:58:49 UTC
Fixed on upstream trunk r1367776

Comment 15 Zdenek Kraus 2012-08-02 08:42:53 UTC
Testing packages:
python-qpid-0.14-10.el5
python-qpid-qmf-0.14-13.el5
qpid-cpp-client-0.14-20.el5
qpid-cpp-client-devel-0.14-20.el5
qpid-cpp-client-devel-docs-0.14-20.el5
qpid-cpp-client-ssl-0.14-20.el5
qpid-cpp-mrg-debuginfo-0.14-18.el5
qpid-cpp-server-0.14-20.el5
qpid-cpp-server-cluster-0.14-20.el5
qpid-cpp-server-devel-0.14-20.el5
qpid-cpp-server-ssl-0.14-20.el5
qpid-cpp-server-store-0.14-20.el5
qpid-cpp-server-xml-0.14-20.el5
qpid-java-client-0.14-3.el5
qpid-java-common-0.14-3.el5
qpid-java-example-0.14-3.el5
qpid-jca-0.14-8.el5
qpid-jca-xarecovery-0.14-8.el5
qpid-qmf-0.14-13.el5
qpid-qmf-devel-0.14-13.el5
qpid-tools-0.14-5.el5

python-qpid-0.14-10.el6_3
python-qpid-qmf-0.14-13.el6_3
qpid-cpp-client-0.14-20.el6_3
qpid-cpp-client-devel-0.14-20.el6_3
qpid-cpp-client-devel-docs-0.14-20.el6_3
qpid-cpp-server-0.14-20.el6_3
qpid-cpp-server-cluster-0.14-20.el6_3
qpid-cpp-server-devel-0.14-20.el6_3
qpid-cpp-server-store-0.14-20.el6_3
qpid-cpp-server-xml-0.14-20.el6_3
qpid-qmf-0.14-13.el6_3
qpid-tools-0.14-5.el6_3

Tested on RHEL5.8, RHEL6.3 & i686, x86_64

Queue is now correctly replicated as exclusive -> VERIFIED

Comment 16 Alan Conway 2012-08-06 14:26:37 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: During an update, ACL rules were preventing access to the cluster-update exchange.
Consequence: new brokers could not join the cluster.
Fix: for catch-up connections, which are authenticated as the cluster-user, allow all access to update state.
Result: Brokers can join the cluster as expected.

Comment 18 errata-xmlrpc 2012-09-19 17:19:59 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/RHSA-2012-1277.html