[KAFKA-7255] Timing issue in SimpleAclAuthorizer with concurrent create/update

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 0.11.0.3, 1.0.2, 1.1.1, 2.0.0
• Fix Version/s: 0.11.0.4, 1.0.3, 1.1.2, 2.0.1, 2.1.0
• Component/s: security
• Assignee: Rajini Sivaram
• Reporter: Rajini Sivaram
• Reviewer: Jun Rao
• Created: 08/Aug/18 09:32
• Updated: 12/Aug/18 18:16
• Resolved: 12/Aug/18 17:44

Description

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.

Issue Links

• links to: GitHub Pull Request #5478