[
https://issues.apache.org/jira/browse/QPID-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved QPID-3799.
-------------------------------
Resolution: Fixed
Fix Version/s: 0.15
Fixed with r1295730
> ACL processing by C++ broker produces unexpected results
> --------------------------------------------------------
>
> Key: QPID-3799
> URL: https://issues.apache.org/jira/browse/QPID-3799
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.14
> Environment: C++ Broker
> Reporter: Chuck Rolke
> Assignee: Chuck Rolke
> Fix For: 0.15
>
>
> There are several instances of C++ ACL-processing code that produce results
> that do not match what would be expected after reading the Developer Pages,
> ACL site page. Clean up of both the site page and the code in a few cases
> requires an agreement on the actual desired behaviour.
> Some of the rule sets below are contrived and not something that a normal
> person would write. However, rule sets may be machine generated or they may
> be in a confused state due to cut and paste errors. Rule processing must be
> predictable regardless of how the rule sets came to be.
> 1. Conflicting permissions rules. Given the following rule set[1]:
> acl allow bob@QPID create queue
> acl deny bob@QPID create queue
> acl allow all all
> What happens when bob tries to create a queue? The site page suggests that
> the rules are processed in order and the first rule that matches defines the
> action to take. By that reading bob should be allowed to create a queue. In
> the C++ broker, however, the first 'acl allow' rule is discarded. Then the
> first rule to match is the deny rule.
> Q1: What is the correct behaviour for the conflicting rules in rule set 1?
> 2. ACL lines greater that 1000 characters are silently truncated. ACL
> processing should stop and emit an error if lines are too long.
> 3. The C++ broker handles some numeric limits on queue creation but these
> limits are not documented in the wiki page.
> We have the following rule set[2]:
> 1. acl allow bob create queue maxqueuesize=1000
> 2. acl deny bob all all
> Line 1 allows bob to create queues as long as the qpid.max_size
> argument in the queue_declare request is<= 1000.
> Line 2 prevents bob from doing anything else.
> We have another rule set[3]:
> 1. acl allow bob create queue maxqueuesize=1000
> 2. acl allow bob create queue maxqueuesize=10000
> 3. acl deny bob all all
> What happens when ACL processing gets to Line 1 when bob tries to create a
> queue with max_size = 2000? Line 1 disallows the creation but Line 2 allows
> it.
> * If code treats the numeric tests as another "comparison criteria" then
> Line 1 will not match. This allows processing to move to Line 2 where the
> action will be allowed.
> * If the code treats the numeric tests as a "deny subclause" then Line 1
> will be a match and bob will be denied.
> Q3: What should happen when bob tries to create a queue with max_size = 2000
> using rule set [3]?
> 4. Numeric limits should work differently on deny rules[4].
> 1. acl deny bob create queue maxqueuesize=1000
> 2. acl allow bob all all
> I suggest that when the numeric tests specifying max values are used as
> "comparison criteria" then:
> * In an allow rule the match is true when the user's value is "less than or
> equal to" the ACL max limit.
> * In a deny rule the match is true when the user's value is "greater than"
> the ACL max limit.
> Q4: How should numeric limits be applied in deny rules?
> I'm interested to know what folks think is the "correct" behaviour for these
> rules and/or how the Java broker would handle them.
--
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:[email protected]
