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

Adjust the judgment logic of topic schema operation permissions #12419

Closed
yuruguo opened this issue Oct 19, 2021 · 3 comments · Fixed by #16018
Closed

Adjust the judgment logic of topic schema operation permissions #12419

yuruguo opened this issue Oct 19, 2021 · 3 comments · Fixed by #16018
Assignees
Labels
lifecycle/stale type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
Milestone

Comments

@yuruguo
Copy link
Contributor

yuruguo commented Oct 19, 2021

Is your enhancement request related to a problem? Please describe.
The role(not super-user) that has the lookup topic permission should also have the operation permission of the topic schema, for example, the role could get topic schema through ./bin/pulsar-admin schemas get tenant1/ns1/tp1.
But I found that we first judge whether the role has access to the tenant of this topic, as below:

public void getSchema(
@PathParam("tenant") String tenant,
@PathParam("namespace") String namespace,
@PathParam("topic") String topic,
@QueryParam("authoritative") @DefaultValue("false") boolean authoritative,
@Suspended final AsyncResponse response
) {
validateTopicName(tenant, namespace, topic);
getSchema(authoritative, response);
}

public void getSchema(boolean authoritative, AsyncResponse response) {
validateDestinationAndAdminOperation(authoritative);
String schemaId = getSchemaId();
pulsar().getSchemaRegistryService().getSchema(schemaId).handle((schema, error) -> {
handleGetSchemaResponse(response, schema, error);
return null;
});
}

private void validateDestinationAndAdminOperation(boolean authoritative) {
try {
validateAdminAccessForTenant(topicName.getTenant());
validateTopicOwnership(topicName, authoritative);

L311's effect is to check the http client role has admin access to the specified tenant.
Since the role only has the authority to lookup this topic, so it cannot be passed.
I have doubts about the rationality of this judgment( call L311), and we should converge the scope of this judgment.

Describe the solution you'd like
Remove this judgment, and replace it with a judgment whether the role has the lookup permission for this topic, as below:

    private void validateDestinationAndAdminOperation(boolean authoritative) {
        try {
            // validateAdminAccessForTenant(topicName.getTenant());
            validateTopicOwnership(topicName, authoritative);
            validateTopicOperation(topicName, TopicOperation.LOOKUP);
@github-actions
Copy link

The issue had no activity for 30 days, mark with Stale label.

@tisonkun
Copy link
Member

tisonkun commented Jul 1, 2022

@yuruguo Perhaps we should reopen this issue before #16018 merged?

@yuruguo
Copy link
Contributor Author

yuruguo commented Jul 7, 2022

@yuruguo Perhaps we should reopen this issue before #16018 merged?

Yep, done.

@yuruguo yuruguo reopened this Jul 7, 2022
@codelipenghui codelipenghui modified the milestones: 2.11.0, 2.12.0 Jul 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants