[chore](dep)upgrade vulnerable dependencies#61893
Merged
CalvinKirs merged 7 commits intoapache:masterfrom Apr 14, 2026
Merged
Conversation
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Member
Author
|
run buildall |
Member
Author
|
run buildall |
TPC-H: Total hot run time: 26799 ms |
TPC-H: Total hot run time: 26705 ms |
TPC-DS: Total hot run time: 169877 ms |
### What problem does this PR solve?
Issue Number: N/A
Related PR: N/A
Problem Summary: Ranger plugin constructors passed serviceName as serviceType. Under Ranger 2.8 the wrong hive service regression exposed this as a null Ranger URL during access-controller initialization. Fix the constructor wiring and update the hive regression case to validate access denial for an invalid Ranger service instead of the old initialization failure.
### Release note
None
### Check List (For Author)
- Test: FE Unit Test
- ./run-fe-ut.sh --run org.apache.doris.mysql.privilege.RangerTest
- Behavior changed: Yes (an invalid Ranger hive service no longer hits the miswired initialization path; access is denied when using the catalog)
- Does this need documentation: No
Member
Author
|
run buildall |
TPC-H: Total hot run time: 26711 ms |
Contributor
FE UT Coverage ReportIncrement line coverage |
TPC-DS: Total hot run time: 168798 ms |
seawinde
reviewed
Mar 31, 2026
| import org.apache.ranger.plugin.service.RangerBasePlugin; | ||
|
|
||
| public class RangerHivePlugin extends RangerBasePlugin { | ||
| private static final String SERVICE_TYPE = "hive"; |
Member
There was a problem hiding this comment.
This change alters the behavior of how serviceName is resolved
Before: The serviceName parameter from the catalog property ranger.service.name was passed as the serviceType to RangerBasePlugin(String serviceType, String appId). The actual serviceName was null, so it was read from the XML config file property ranger.plugin serviceType.service.name.
After: serviceType is hardcoded to "hive", and the serviceName is directly taken from the catalog property ranger.service.name via RangerBasePlugin(String serviceType, String serviceName, String appId), bypassing the XML config file.
This fixes a semantic issue where serviceType and serviceName were conflated, but introduces a behavioral change:
1. Config file lookup is now stable. Previously, if ranger.service.name=my_custom_hive, the plugin would look for ranger-my_custom_hive-security.xml, which is incorrect. Now it always loads ranger-hive-security.xml.
2. serviceName source changed. Previously it was read from the XML property ranger.plugin.{serviceType}.service.name; now it comes directly from the catalog property ranger.service.name. For existing users who had a different serviceName configured in their XML
file (e.g., ranger.plugin.hive.service.name=hive_prod), that XML setting will no longer take effect after the upgrade.
if ranger.plugin.hive.service.name=hive_prod and catalog service name is hive in low version，after upgrade, would cause err info which is can not found service name
The same change applies to RangerDorisPlugin.
Member
Author
There was a problem hiding this comment.
We need to consider a compatibility strategy, but it won’t be implemented in this PR. The primary scenario here is a reverse (backward) compatibility case, so I’ve added a flag to skip it.
### What problem does this PR solve? Issue Number: N/A Related PR: N/A Problem Summary: The external hive regression suite included a wrong-ranger-service subcase that now depends on a Ranger-enabled environment after the Ranger plugin wiring fix. Guard that subcase with enableRangerTest so the suite skips it when Ranger is not configured, while preserving the access denied assertion when Ranger tests are enabled. ### Release note None ### Check List (For Author) - Test: No need to test (regression-only guard change; tests were not run in this session) - Behavior changed: Yes (the Ranger-specific hive subcase now runs only when enableRangerTest is true) - Does this need documentation: No
Member
Author
|
run buildall |
TPC-H: Total hot run time: 26507 ms |
TPC-DS: Total hot run time: 169645 ms |
morningman
previously approved these changes
Apr 7, 2026
github-actions
bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
Member
Author
|
run buildall |
github-actions
bot
removed
the
approved
### What problem does this PR solve? Issue Number: N/A Related PR: apache#62277 Problem Summary: Revert the Ranger plugin service type changes and related tests so these files match rich/master again. ### Release note None ### Check List (For Author) - Test: No need to test - This commit only reverts branch-local changes and restores rich/master behavior for these files. - Behavior changed: No - Does this need documentation: No
Member
Author
|
run buildall |
morningman
approved these changes
Apr 14, 2026
github-actions
bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
hubgeter
approved these changes
Apr 14, 2026
Member
Author
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Blocking issue:
- Upgrading
ranger-plugins-commonto 2.8.0 is not paired with the FE wrapper fix that this code path still needs.RangerHivePluginandRangerDorisPluginstill callRangerBasePluginassuper(serviceName, null, null)/super(serviceName, null), but upstream interprets the first constructor argument asserviceType, notserviceName, in both Ranger 2.7 and 2.8. The runtime pathCatalogFactory.createCatalog()->ExternalCatalog.initAccessController()->RangerHiveAccessController()therefore still constructs the plugin with the catalog's configured service name in theserviceTypeslot. The companion fix that corrected this was reverted in this PR history, so the dependency bump is left without the compatibility change it depends on.
Critical checkpoint conclusions:
- Goal of the task: Not fully accomplished. The dependency version changes, but the PR does not prove or preserve correct Ranger-backed catalog behavior after the upgrade.
- Small / clear / focused: Yes, but incomplete. The change is narrow, yet it omits the FE compatibility fix required by the upgraded dependency.
- Concurrency: Not applicable for this patch; no new concurrent state or locking changes were introduced.
- Lifecycle / initialization: Applicable and problematic. The failure is in access-controller/plugin initialization during catalog creation.
- Configuration items: No new config items were added; the new
enableRangerTestguard is understandable, but it also removes the only regression signal from environments without Ranger. - Incompatible changes / compatibility: Applicable and failing. This is a dependency-interface compatibility change at the FE/Ranger boundary, but no matching compatibility code remains in the net diff.
- Parallel code paths: Applicable. Both Hive and Doris Ranger plugin wrappers share the same constructor misuse, so the issue is not isolated to one path.
- Special conditional checks: Applicable. The new guard is simple, but it masks the integration failure instead of validating the upgraded dependency end to end.
- Test coverage: Insufficient for this upgrade. The regression case is gated on
enableRangerTest, and the wrapper-focused FE tests from the reverted fix are no longer present in the final PR state. - Observability: Existing error surfacing is adequate for initialization failure; no additional observability issue is the blocker here.
- Transaction / persistence / data writes / FE-BE variable passing: Not applicable.
- Performance: No material performance concern found in the changed lines.
- Other issues: None beyond the blocking compatibility problem above.
CalvinKirs
dismissed
github-actions[bot]’s stale review
We need to consider a compatibility strategy, but it won’t be implemented in this PR. The primary scenario here is a reverse (backward) compatibility case, so I’ve added a flag to skip it.
github-actions bot
pushed a commit
that referenced
this pull request
Apr 14, 2026
upgrade ranger to 2.8.0
github-actions bot
pushed a commit
that referenced
this pull request
Apr 14, 2026
upgrade ranger to 2.8.0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
upgrade ranger to 2.8.0