RANGER-5739: Recursive URL resource policy does not match resources e… - #1150
Open
vyommani wants to merge 1 commit into
Open
RANGER-5739: Recursive URL resource policy does not match resources e…#1150vyommani wants to merge 1 commit into
vyommani wants to merge 1 commit into
Conversation
…xpressed in the default-FileSystem URL form (scheme:///path)
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
1 participant
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.
What changes were proposed in this pull request?
RangerURLResourceMatcher did not match a recursive URL policy against a resource when both were expressed in the scheme:///path form (three slashes after the colon) — the standard way to reference the Hadoop default FileSystem, i.e. a URL with no explicit host/authority.
RangerURLResourceMatcher.isPathURLType() rejected any URL whose scheme was followed by 3 or more slashes, mis-classifying the default-FS form as "not a URL." isRecursiveWildCardMatch() short-circuits to false whenever isPathURLType() is false, so path-element comparison never ran for these URLs
isPathURLType(): a path-URL is now any scheme: followed by 2 or more slashes, not exactly 2.
getScheme() / getPathWithOutScheme(): rather than hard-coding "2 slashes" into the scheme boundary, these now capture all of the slashes immediately following the colon. This is needed for correctness, not just to lift the isPathURLType gate — without it, path-element reconstruction in isRecursiveWildCardMatch collapses the extra slash and a default-FS resource (hdfs:///app/...) could wrongly match a policy scoped to an explicit authority literally named app (hdfs://app/...), or vice versa. Preserving the exact slash count keeps those two forms distinct while letting like-for-like default-FS policy/resource pairs match as expected.
The regex used by isPathURLType() is now compiled once into a static final Pattern field rather than per call, matching the existing convention elsewhere in this package (RangerIpMatcher, RangerTimeOfDayMatcher).
How was this patch tested?
Added new tests