[
https://issues.apache.org/jira/browse/KAFKA-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Arthur resolved KAFKA-14214.
----------------------------------
Resolution: Fixed
> StandardAuthorizer may transiently process ACLs out of write order
> ------------------------------------------------------------------
>
> Key: KAFKA-14214
> URL: https://issues.apache.org/jira/browse/KAFKA-14214
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Akhilesh Chaganti
> Assignee: Akhilesh Chaganti
> Priority: Blocker
> Fix For: 3.3.0
>
>
> The issue with StandardAuthorizer#authorize is, that it looks up
> aclsByResources (which is of type ConcurrentSkipListMap)twice for every
> authorize call and uses Iterator with weak consistency guarantees on top of
> aclsByResources. This can cause the authorize function call to process the
> concurrent writes out of order.
> *Issue 1:*
> When StandardAuthorizer calls into a simple authorize function, we check the
> ACLs for literal/prefix matches for the resource and then make one more call
> to check the ACLs for matching wildcard entries. Between the two
> (checkSection) calls, let’s assume we add a DENY for resource literal and add
> an ALLOW ALL wildcard. The first call to check literal/prefix rules will SKIP
> DENY ACL since the writes are not yet processed and the second call would
> find ALLOW wildcard entry which results in ALLOW authorization for the
> resource when it is actually DENY.
> *Issue: 2*
> For authorization, StandardAuthorizer depends on an iterator that iterates
> through the ordered set of ACLs. The iterator has weak consistency
> guarantees. So when writes for two ACLs occur, one of the ACLs might be still
> visible to the iterator while the other is not.
> Let’s say below two ACLS are getting added in the following order to the set.
> Acl1 = StandardAcl(TOPIC, foobar, LITERAL, DENY, READ, user1)
> Acl2 = StandardAcl(TOPIC, foo, PREFIX, ALLOW, READ, user1)
> Depending on the position of the iterator on the ordered set during the write
> call, the iterator might just see Acl2 which prompts it to ALLOW the topic to
> be READ even though the DENY rule was written before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
