RANGER-5225: Override policy should take precedence over normal deny policy

[fateh288]

What changes were proposed in this pull request?

Steps to reproduce:
Tag an hdfs path /override-path in atlas as PII
Deny PII policy for user userx
Allow override policy for user userx
hdfs dfs -ls /override-path
User gets access denied. 
Expected behavior is access allowed

Behavior also reproducible by additional unit tests in policy engine

The PR fixes the bug wherein allow result overrides the previous deny result if priority of allow policy is greater than the priority of the deny policy

How was this patch tested?

Added new unit tests which failed without the proposed changes.
The new unit tests pass after the bug fix.

[Copilot]

Pull Request Overview

This PR ensures that override (allow) policies with higher priority correctly take precedence over normal deny policies by expanding test coverage and updating the evaluator logic.

• Added new Hive and HDFS JSON test cases to validate override behavior
• Modified RangerDefaultPolicyEvaluator to apply allow results when override policy priority is higher than a previous deny
• Updated resource test definitions to include override scenarios

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
agents-common/src/test/resources/policyengine/test_policyengine_tag_hive.json	Added Hive override test entries under PII tag policy
agents-common/src/test/resources/policyengine/test_policyengine_tag_hdfs.json	Added HDFS override test case for recursive path /override-resource
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java	Changed policy evaluation logic to handle allow overrides based on priority

[Copilot]

This inner allow check does not include the same context condition (oneRequest.isAccessTypeAny() || RangerAccessRequestUtil.getIsAnyAccessInContext) used in the initial allow branch; add it to maintain consistent override behavior.

Suggested change

	if (allowResult != null) {
	if (allowResult != null && (oneRequest.isAccessTypeAny() || RangerAccessRequestUtil.getIsAnyAccessInContext(oneRequest.getContext()))) {

[fateh288]

We don't want this condition check of "is any access" here - condition valid for other access types

[fateh288]

The below condition will be false for the scenario being tested because access type any would be false, but we still would want allowResult to override the previous result
&& (oneRequest.isAccessTypeAny() || RangerAccessRequestUtil.getIsAnyAccessInContext(oneRequest.getContext())

[fateh288]

@mneethiraj
Can you explain why we have different behavior for anyAccess ?

Can we simplify the code to below irrespective of whether access type is any or not ? (I can't understand the case when the policy priority is same as old priority (i.e. why >= is there in the first condition and not >) .

if (getPolicyPriority() > oldPriority) {
          if (allowResult != null) {
              accessTypeResults.put(accessType, allowResult);
          }
          else if (denyResult != null) {
              accessTypeResults.put(accessType, denyResult);
          }
}