Bug 814356

Summary: createSender() ignores 'create: never'
Product: Red Hat Enterprise MRG Reporter: Ed Santiago <santiago>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED ERRATA QA Contact: Leonid Zhaldybin <lzhaldyb>
Severity: medium Docs Contact:
Priority: medium    
Version: DevelopmentCC: esammons, jross, lzhaldyb, mcressma, timp
Target Milestone: 2.3   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-cpp-0.18-1 Doc Type: Bug Fix
Doc Text:
Cause: The broker required create permission for user sessions performing a passive declare (i.e. a declare that should not create, but should merely verify existence). Consequence: This resulted in clients that were not actually trying to create an exchange receiving permission errors due to the lack of create permission. Fix: if the declare is passive, the permission required was changed to access rather than create. Result: Clients using but never creating exchanges need not have create permission granted.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-06 18:55:47 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:

Description Ed Santiago 2012-04-19 16:39:11 UTC
It would seem that the C++ bindings are ignoring 'create: never'. This makes it impossible for a client to publish on a broker whose ACLs prevent creating an exchange.

To reproduce, use the 'spout' client packaged with qpid-cpp-client-devel:

  1) Set up ACLs on the broker such that a given user U cannot create exchanges

  2) Create (as admin @ broker) topic exchange 'my.topic';

  3) As user U:

    $ ./spout --content foo  --broker [...]  'my.topic; { create: never }'
    2012-04-19 12:26:58 warning Exception received from broker: unauthorized-access: unauthorized-access: ACL denied exchange create request from xxxxx@KRBDOMAIN (qpid/broker/SessionAdapter.cpp:87) [caused by 2 \x07:\x01]

Confirmed with qpid-cpp-client-devel 0.14-1.fc16.1 and 0.12-6.el6. 100% reproducible.

Comment 1 Gordon Sim 2012-04-20 08:25:04 UTC
This is not an issue with the client not honouring the create policy, it is an issue with an odd implementation choice in the ACL code.

If you do a passive declare (which should simply assert that the exchange in question exists without creating it if it does not), the ACL checks the 'create' permission for the exchange. (See qpid/broker/SessionAdapter.cpp line 87 in latest code, i.e. qpid::broker::SessionAdapter::ExchangeHandlerImpl::declare).

I raised this question on the dev list but don't recall getting an answer. My suggestion would be to change the ACL check for passive declares to check for ACT_ACCESS. (The set of actions is very poorly thought through.)

Comment 2 Gordon Sim 2012-04-20 09:49:08 UTC
Note: There is a 'passive' property that can be specified to give explicit permission for passive declares; its a 'create' permission with property 'passive' set to true however, which is odd. A passive declare is much like e.g. a query which requires the 'access' permission.

Comment 3 Gordon Sim 2012-04-20 10:46:21 UTC
A proposal for making the ACL model more intuitive (logically correct) has been posted upstream for comment: https://reviews.apache.org/r/4827/

Note that this change would require changes for some existing ACLs (though in which the passive option to create is used to explicitly distinguish passive declares).

The workaround of course is just to use the ACLs as defined, and add a rule in to allow passive declares.

Comment 4 Gordon Sim 2012-04-20 14:29:50 UTC
Change to ACL committed upstream: http://svn.apache.org/viewvc?rev=1328384&view=rev

Comment 6 Leonid Zhaldybin 2012-11-01 09:40:15 UTC
Tested on RHEL5.8 and RHEL6.3 (both i386 and x86_64). The user which is forbidden to create exchanges (or queues) by ACL rule, can now send messages to an existing exchange (or queue) even if 'create: never' option is used in address string.

-> VERIFIED

Comment 8 errata-xmlrpc 2013-03-06 18:55:47 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-2013-0561.html