[jira] [Created] (KAFKA-14214) StandardAuthorizer may transiently process ACLs out of write order

["Akhilesh Chaganti (Jira)" <ji...@apache.org>]

Akhilesh Chaganti created KAFKA-14214:
-----------------------------------------

             Summary: 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


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)