Skip to content
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

[improve][broker] Support revoking permission for AuthorizationProvider #20456

Merged
merged 4 commits into from
Jun 2, 2023

Conversation

Technoboy-
Copy link
Contributor

Motivation

Current AuthorizationProvider does not actually fully support the revocation of ACLs :

Documentation

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

@Technoboy- Technoboy- self-assigned this Jun 1, 2023
@Technoboy- Technoboy- added this to the 3.1.0 milestone Jun 1, 2023
@Technoboy- Technoboy- added type/feature The PR added a new feature or issue requested a new feature area/broker labels Jun 1, 2023
@github-actions github-actions bot added the doc-not-needed Your PR changes do not impact docs label Jun 1, 2023
@Technoboy- Technoboy- changed the title [feat][broker] Support revoking permission for AuthorizationProvider.java [feat][broker] Support revoking permission for AuthorizationProvider Jun 1, 2023
@Technoboy- Technoboy- changed the title [feat][broker] Support revoking permission for AuthorizationProvider [improve][broker] Support revoking permission for AuthorizationProvider Jun 1, 2023
Copy link
Member

@jiazhai jiazhai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the help. overall lgtm. Added some minor comments.

* @param role
* @return
*/
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a default implementation here? How about removing it so that we can keep aligned with other APIs in this file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’s better to have default implementations here, otherwise it will cause compile issue when upgrade.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, also the "revoke" is already broken today when using a custom authz plugin. Even if today it succeeds, the revoke does nothing because it would just try to remove the ACL from zookeeper, where there are not any.

* @return CompletableFuture<Void>
*/
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) {
return FutureUtil.failedFuture(new IllegalStateException(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe java.lang.UnsupportedOperationException is more suitable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd better keep the same exception as with other default implementation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree.

@lifepuzzlefun
Copy link
Contributor

lifepuzzlefun commented Jun 1, 2023

I have the same question as jiazhai if the default method is return CompletableFuture with Exception.
maybe we need cover the exception in the outer admin api handler to avoid earlier version of user-define AuthorizationProvider fail.

@Technoboy-
Copy link
Contributor Author

I have the same question as jizhai if the default method is return CompletableFuture with Exception. maybe we need cover the exception in the outer admin api handler to avoid earlier version of user-define AuthorizationProvider fail.

I may not get what you mean. Earlier version won't fail

* @param role
* @return
*/
default CompletableFuture<Void> revokePermissionAsync(NamespaceName namespace, String role) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, also the "revoke" is already broken today when using a custom authz plugin. Even if today it succeeds, the revoke does nothing because it would just try to remove the ACL from zookeeper, where there are not any.

@lifepuzzlefun
Copy link
Contributor

I have the same question as jizhai if the default method is return CompletableFuture with Exception. maybe we need cover the exception in the outer admin api handler to avoid earlier version of user-define AuthorizationProvider fail.

I may not get what you mean. Earlier version won't fail

Sorry for my misunderstanding comments. I mean that if previous version user-define AuthorizationProvider didn't override the default method. when user call the admin api and execute the default method. will it be failed ? like org.apache.pulsar.broker.authorization.MockAuthorizationProvider.

@Technoboy-
Copy link
Contributor Author

I have the same question as jizhai if the default method is return CompletableFuture with Exception. maybe we need cover the exception in the outer admin api handler to avoid earlier version of user-define AuthorizationProvider fail.

I may not get what you mean. Earlier version won't fail

Sorry for my misunderstanding comments. I mean that if previous version user-define AuthorizationProvider didn't override the default method. when user call the admin api and execute the default method. will it be failed ? like org.apache.pulsar.broker.authorization.MockAuthorizationProvider.

Ah, yes, it will fail in this case

@codecov-commenter
Copy link

codecov-commenter commented Jun 2, 2023

Codecov Report

Attention: Patch coverage is 57.89474% with 16 lines in your changes missing coverage. Please review.

Project coverage is 72.91%. Comparing base (5e6e6ce) to head (4bf5972).
Report is 1288 commits behind head on master.

Files with missing lines Patch % Lines
...ker/authorization/PulsarAuthorizationProvider.java 61.29% 8 Missing and 4 partials ⚠️
...ar/broker/authorization/AuthorizationProvider.java 0.00% 4 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #20456      +/-   ##
============================================
- Coverage     72.95%   72.91%   -0.04%     
- Complexity    31914    31916       +2     
============================================
  Files          1867     1867              
  Lines        138485   138522      +37     
  Branches      15202    15204       +2     
============================================
- Hits         101037   101009      -28     
- Misses        29438    29503      +65     
  Partials       8010     8010              
Flag Coverage Δ
inttests 24.16% <0.00%> (+0.04%) ⬆️
systests 24.96% <2.63%> (-0.08%) ⬇️
unittests 72.20% <57.89%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
...sar/broker/authorization/AuthorizationService.java 57.53% <100.00%> (+0.33%) ⬆️
...ar/broker/authorization/AuthorizationProvider.java 8.51% <0.00%> (-0.80%) ⬇️
...ker/authorization/PulsarAuthorizationProvider.java 71.19% <61.29%> (-1.45%) ⬇️

... and 62 files with indirect coverage changes

Copy link
Contributor

@codelipenghui codelipenghui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Technoboy- It looks like you will create another PR to make sure all the revoking calls point to the newly added method, right?

@Technoboy-
Copy link
Contributor Author

LGTM

@Technoboy- It looks like you will create another PR to make sure all the revoking calls point to the newly added method, right?

yes, right.

Copy link
Member

@michaeljmarshall michaeljmarshall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this API expansion. It would have been nice to send a notice to the private or dev list, though. Thanks.

@michaeljmarshall
Copy link
Member

@Technoboy- - one important detail that we should also cover is the fact that all of the "get permission" endpoints make the assumption that the permissions are stored in zk. We should probably expand the AuthorizationProvider to include get methods.

@merlimat
Copy link
Contributor

merlimat commented Jun 3, 2023

@Technoboy- - one important detail that we should also cover is the fact that all of the "get permission" endpoints make the assumption that the permissions are stored in zk. We should probably expand the AuthorizationProvider to include get methods.

I think these might be trickier to support. Many backends would not be able to answer that question directly (or at least the broker might not have access to it).

@michaeljmarshall
Copy link
Member

michaeljmarshall commented Jun 3, 2023

That's fair, but I think it might make sense to let the interface's implementation decide how to handle that instead of reading potentially irrelevant information from the metadata store. I don't think it has to be fixed along with this PR, but in my opinion, that is the right direction.

@merlimat
Copy link
Contributor

merlimat commented Jun 3, 2023

Sure, it makes sense. Right now it's anyway broken when it returns an empty list

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/broker doc-not-needed Your PR changes do not impact docs ready-to-test type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants