thetumbled opened a new pull request, #22579: URL: https://github.com/apache/pulsar/pull/22579
### Motivation Motivated by the permission hole described in https://github.com/apache/pulsar/pull/22564. - In a typical Pulsar deployment, we set `authenticationEnabled=true` and `authorizationEnabled=true` to enable authentication and authorization. - When users want to create a subscription in the management platform, we will grant the `consume` permission of topic and the permission of that subscription to the user's token. so that user can create a subscription successfully. - We also set config `allowAutoSubscriptionCreation` to be true to allow user creating subscriptions automatically if user's token has the `consume` permission. But, **auto-creation of subscriptions will not grant the permission of the subscription to the user's token**. - The permission control flow of subscription: - we can only grant and revoke the permission of a subscription by the `grant-permission` and `revoke-permission` REST API. - The permission of subscription is in the namespace level. When a user creates a subscription `sub` for topic `persistent://public/default/test`, broker will check if user's token has the `consume` permission of `persistent://public/default/test`, if yes, broker will retrieve the permission of all subscriptions under the namespace `public/default` and get the role list of subscription `sub`. - **If the role list is empty or null, broker allow to create the subscription.** However, the permission of the subscription is still not granted to the user's token. - If the role list is not empty, broker will check if the role corresponding to the user's token is in the role list. If yes, broker allow to create the subscription. - If the role corresponding to the user's token is not in the role list, broker will reject the request. There is a permission hole in the current design. If a user obtain the `consume` permission of a topic in management platform, he can create infinite subscriptions without notifying the administrator. For example, user `jack` can obtain the `consume` permission of topic `persistent://public/default/test` and the permission of subscription `sub` in management platform. At this time, the role list under the namespace `public/default` is ``` 'sub' -> ['jack'] ``` Then, user `jack` can create other subscriptions `sub1`, `sub2`,... for topic `persistent://public/default/test` without notifying the administrator. The role list under the namespace `public/default` remain unchanged as ``` 'sub' -> ['jack'] ``` The administrator can't know who is the owner of the subscriptions `sub1`, `sub2`,... What is worse, if another user `tom` obtain the permission of subscription `sub1` under the same namespace `public/default` in management platform, that result into the role list under the namespace `public/default` become to ``` 'sub' -> ['jack'] 'sub1' -> ['tom'] ``` `jack` lose the permission of subscription `sub1` immediately. Because jack do not have the permission of subscription `sub1` really. He just uses an unregistered subscription `sub1` owned by nobody to consume the messages. Once there are any people obtain the permission of subscription `sub1`, his task consuming `sub1` will be shutdown immediately. ### Modifications Do not allow to subscribe if the role do not have the permission really. ### Verifying this change - [ ] Make sure that the change passes the CI checks. *(Please pick either of the following options)* This change is a trivial rework / code cleanup without any test coverage. *(or)* This change is already covered by existing tests, such as *(please describe tests)*. *(or)* This change added tests and can be verified as follows: *(example:)* - *Added integration tests for end-to-end deployment with large payloads (10MB)* - *Extended integration test for recovery after broker failure* ### Does this pull request potentially affect one of the following parts: <!-- DO NOT REMOVE THIS SECTION. CHECK THE PROPER BOX ONLY. --> *If the box was checked, please highlight the changes* - [ ] Dependencies (add or upgrade a dependency) - [ ] The public API - [ ] The schema - [ ] The default values of configurations - [ ] The threading model - [ ] The binary protocol - [ ] The REST endpoints - [ ] The admin CLI options - [ ] The metrics - [ ] Anything that affects deployment ### Documentation <!-- DO NOT REMOVE THIS SECTION. CHECK THE PROPER BOX ONLY. --> - [ ] `doc` <!-- Your PR contains doc changes. --> - [ ] `doc-required` <!-- Your PR changes impact docs and you will update later --> - [ ] `doc-not-needed` <!-- Your PR changes do not impact docs --> - [ ] `doc-complete` <!-- Docs have been already added --> ### Matching PR in forked repository PR in forked repository: <!-- ENTER URL HERE --> -- 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]
