[
https://issues.apache.org/jira/browse/KAFKA-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram resolved KAFKA-7255.
-----------------------------------
Resolution: Fixed
> Timing issue in SimpleAclAuthorizer with concurrent create/update
> -----------------------------------------------------------------
>
> Key: KAFKA-7255
> URL: https://issues.apache.org/jira/browse/KAFKA-7255
> Project: Kafka
> Issue Type: Bug
> Components: security
> Affects Versions: 0.11.0.3, 1.0.2, 1.1.1, 2.0.0
> Reporter: Rajini Sivaram
> Assignee: Rajini Sivaram
> Priority: Blocker
> Fix For: 0.11.0.4, 1.0.3, 1.1.2, 2.0.1, 2.1.0
>
>
> There is a small timing window in SimpleAclAuthorizer where ACL updates may
> be lost if two brokers create ACLs for a resource at the same time.
> Scenario: Administrator creates new.topic and sends one ACL request to add
> ACL for UserA for new.topic and a second request to add ACL for UserB for
> new.topic using AdminClient. These requests may be sent to different brokers
> by AdminClient. In most cases, both ACLs are added for the resource
> new.topic, but there is a small timing window where one broker may overwrite
> the ACL written by the other broker, resulting in only one of the ACLs
> (either UserA or UserB) being actually stored in ZooKeeper. The timing window
> itself is very small, but we have seen intermittent failures in
> SimpleAclAuthorizerTest.testHighConcurrencyModificationOfResourceAcls as a
> result of this window.
> Even though this issue can result in incorrect ACLs affecting security, we
> have not raised this as a security vulnerability since this is not an
> exploitable issue. ACLs can only be set by privileged users in Kafka who have
> Alter access on the Cluster resource. Users without this privileged access
> cannot use this issue to gain additional access to any resource.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
