New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can not revoke permission after update topic partition #16768
Comments
The issue had no activity for 30 days, mark with Stale label. |
In the event that revoking this permission is really important, I think the current workaround would be to grant permission on the "new" partitions, and then revoke permission for the partitioned topic itself. |
The issue had no activity for 30 days, mark with Stale label. |
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
The text was updated successfully, but these errors were encountered: