Skip to content

[Bug] [API] Alert plugin instance APIs miss permission checks #18276

@ruanwenjun

Description

@ruanwenjun

Search before asking

I searched existing issues for AlertPluginInstanceController permission and alert plugin instance permission and did not find a similar report.

What happened

On the current dev branch, several alert plugin instance APIs do not enforce the alert plugin instance permission consistently.

Code paths observed at commit cd8abbaa626d1b7da229fc6883cbb80b687428d6:

  • GET /alert-plugin-instances/list calls AlertPluginInstanceService.queryAll() without passing loginUser.
  • GET /alert-plugin-instances/verify-name calls AlertPluginInstanceService.checkExistPluginInstanceName(...) without any permission check.
  • GET /alert-plugin-instances calls AlertPluginInstanceService.listPaging(loginUser, ...), but the implementation ignores loginUser and queries all matching alert plugin instances.

In AlertPluginInstanceServiceImpl, create, updateById, deleteById, and getById call canOperatorPermissions(...) with AuthorizationType.ALERT_PLUGIN_INSTANCE, but queryAll, checkExistPluginInstanceName, and listPaging do not perform permission checks or resource filtering.

This is inconsistent with nearby APIs such as AlertGroupServiceImpl, where list/query methods filter non-admin users by authorized resource ids before returning data.

What you expected to happen

Alert plugin instance query and validation APIs should enforce permissions consistently.

Users without alert plugin instance view/manage permission should not be able to list all alert plugin instances or infer instance names through the verify-name endpoint. Depending on the intended authorization model, these APIs should either return USER_NO_OPERATION_PERM or only return resources the current user is authorized to view.

How to reproduce

  1. Use the current dev branch.
  2. Create or use a non-admin user that does not have alert plugin instance view/manage permission.
  3. Call the following APIs:
    • GET /dolphinscheduler/alert-plugin-instances
    • GET /dolphinscheduler/alert-plugin-instances/list
    • GET /dolphinscheduler/alert-plugin-instances/verify-name?alertInstanceName=<name>
  4. Observe that these code paths are served by unfiltered mapper queries or name-existence checks instead of permission denial or authorized-resource filtering.

Anything else

Relevant files:

  • dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/controller/AlertPluginInstanceController.java
  • dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertPluginInstanceServiceImpl.java
  • dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertGroupServiceImpl.java

A fix should probably add permission checks or authorized-resource filtering to queryAll, checkExistPluginInstanceName, and listPaging, plus tests for unauthorized users.

Version

dev

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions