TakaHiR07 opened a new issue, #16768:
URL: https://github.com/apache/pulsar/issues/16768

   **Describe the bug**
   Steps to reproduce the behavior:
   1. create a 3 partition topic "persistent://test/test/test"
   2. grant produce permission on topic
   3. update topic partition to 5
   4. pulsar-admin topics permissions persistent://test/test/test-partition-5, 
can not get permission of the new partition, but old partition has the 
permission
   5. 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
   
   This 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 
https://github.com/apache/pulsar/pull/10333)
   
![企业微信截图_0a8acc9d-beb1-4c98-b8c0-986a8eca8b20](https://user-images.githubusercontent.com/13505225/180725749-fa1bcfc0-a886-4318-acaa-7cd148c08127.png)
   
![企业微信截图_317b5026-fd44-469f-a4c2-751b57d43b63](https://user-images.githubusercontent.com/13505225/180725893-de718381-e9ed-4034-935c-f8e1c7d45e98.png)
   
   
   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. 
   
   
   **Expected behavior**
   remove grant permission for each partition in 
internalGrantPermissionsOnTopic()
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to