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)
