Describe the bug
Steps to reproduce the behavior:
- create a 3 partition topic "persistent://test/test/test"
- grant produce permission on topic
- update topic partition to 5
- pulsar-admin topics permissions persistent://test/test/test-partition-5, can not get permission of the new partition, but old partition has the permission
- try to produce msg to "persistent://test/test/test", "persistent://test/test/test-partition-0", "persistent://test/test/test-partition-4", all of them succeed
- pulsar-admin topics revoke-permission --role xxx persistent://test/test/test, would throw exception:
"Failed to perform http delete request: javax.ws.rs.ClientErrorException: HTTP 412 Permissions are not set at the topic level"
- revoke permission failed and still can produce msg to topic "persistent://test/test/test"
step 1-5 means the updated partition actually has the permission, but the metadata in zk is inconsistent.
When I dive into the code, internalGrantPermissionsOnTopic() would traverse each partition and grant permission. And when do permission checking in PulsarAuthorizationProvider#checkPermission(), it would use partitionedTopicName to judge whether has the permission(proposed in #10333)
Therefore, it is no need to grant permission for each partition, which not only leads to misleading zk metadata, but also introduces additional operation time overhead.
step 6-7, means we can not revoke the permission after topic update partition, and still can produce msg
The problem is similar, internalRevokePermissionsOnTopic() would firstly traverse each partition and revoke partition permission, and finally revoke partitionedTopic permission. When revoke the permission of "persistent://test/test/test-partition-4", the permission is not existed thus throw exception and skip revoke partitionedTopic permission.
Therefore although revoke partition permission successfully, the partitionedTopic permission also exist, while pr-10333 check permission by partitionedTopicName.
master branch, branch-2.9, branch-2.8 all have the same problem
Expected behavior
no need to grant permission for each partition in internalGrantPermissionsOnTopic()
do not revoke permission for each partition in internalRevokePermissionsOnTopic()
internalGetPermissionsOnTopic() should get the partitionedTopic permission
Describe the bug
Steps to reproduce the behavior:
"Failed to perform http delete request: javax.ws.rs.ClientErrorException: HTTP 412 Permissions are not set at the topic level"
step 1-5 means the updated partition actually has the permission, but the metadata in zk is inconsistent.
When I dive into the code, internalGrantPermissionsOnTopic() would traverse each partition and grant permission. And when do permission checking in PulsarAuthorizationProvider#checkPermission(), it would use partitionedTopicName to judge whether has the permission(proposed in #10333)
Therefore, it is no need to grant permission for each partition, which not only leads to misleading zk metadata, but also introduces additional operation time overhead.
step 6-7, means we can not revoke the permission after topic update partition, and still can produce msg
The problem is similar, internalRevokePermissionsOnTopic() would firstly traverse each partition and revoke partition permission, and finally revoke partitionedTopic permission. When revoke the permission of "persistent://test/test/test-partition-4", the permission is not existed thus throw exception and skip revoke partitionedTopic permission.
Therefore although revoke partition permission successfully, the partitionedTopic permission also exist, while pr-10333 check permission by partitionedTopicName.
master branch, branch-2.9, branch-2.8 all have the same problem
Expected behavior
no need to grant permission for each partition in internalGrantPermissionsOnTopic()
do not revoke permission for each partition in internalRevokePermissionsOnTopic()
internalGetPermissionsOnTopic() should get the partitionedTopic permission