qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (QPID-3544) ACL denials while replicating exclusive queues to a newly joined node
Date Wed, 12 Oct 2011 14:33:12 GMT
ACL denials while replicating exclusive queues to a newly joined node

                 Key: QPID-3544
                 URL: https://issues.apache.org/jira/browse/QPID-3544
             Project: Qpid
          Issue Type: Bug
          Components: C++ Clustering
    Affects Versions: 0.13
            Reporter: Alan Conway
            Assignee: Alan Conway

(from https://bugzilla.redhat.com/show_bug.cgi?id=689408)
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):

How reproducible:

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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message