[ 
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)

Reply via email to