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.
Fixed on trunk: r1182451 | QPID-3544: ACL denials while replicating exclusive queues to a newly joined node.
Note: fix on trunk was incomplete, also need this commit: r1182451 | QPID-3544: ACL denials while replicating exclusive queues to a newly joined node
Typo in comment 5, the additional commit is:r1182514
*** Bug 809460 has been marked as a duplicate of this bug. ***
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
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.
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.
Fixed on upstream trunk r1367776
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
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.
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