RANGER-5628: Gate Ozone action-matches policy behind feature flags

[ramackri]

Summary

Aligns Ozone action-matches gating (RANGER-5628) with the single-property design from master PR #1073 (RANGER-5687), adapted for ranger-2.9.

One property controls everything (default off):

Property	File
ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition	ranger-admin-site.xml / ranger-admin-default-site.xml

Propagates via service-def option enableActionMatcherInPoliciesCondition to:

• Admin UI — RangerServiceDefService.applyActionMatcherInPoliciesConditionHiddenOption() filters or restores action-matches when serving the ozone service-def API
• Ozone plugin — RangerOzoneAuthorizer.isOzoneActionPolicyEnabled() reads the option from the downloaded service-def
• STS / inline — action gating is confined to plugin-ozone; generic RangerInlinePolicyEvaluator always evaluates actions if present on a grant
• DB patch J10065 — applies embedded policy conditions and persists enableActionMatcherInPoliciesCondition in def_options; excludes action-matches when flag is off at patch time

Runtime fix (commit 4107076af)

After J10065 persists enableActionMatcherInPoliciesCondition=false in DB def_options, admin site config is authoritative at runtime (same fix as #1073 c345373fe):

• Setting the property to true in ranger-admin-site.xml and restarting Admin takes effect even when DB still has false
• action-matches is restored from the embedded ozone service-def when enabled but missing from DB (e.g. J10065 removed it earlier)
• No manual def_options SQL or re-running J10065 is required for Admin UI / API behavior

Audit: When flag is off, authorizer sets request.action to coarse access type (read/write) so Solr access is populated (pre-5628 behavior). S3 action is used only when flag is on.

Related: Builds on Ozone action-matches work (#1054 / PatchForOzoneServiceDefPolicyConditionUpdate_J10065).

Ozone action-policy gating (isOzoneActionPolicyEnabled)

isOzoneActionPolicyEnabled(plugin) is a private helper in RangerOzoneAuthorizer that answers: should this OM enforce fine-grained S3 actions (e.g. GetObject, PutObject) or only coarse Ozone permissions (read, write, list)?

It reads enableActionMatcherInPoliciesCondition from plugin.getServiceDef().getOptions() (populated by Admin from site config). Default is false.

All gating stays in plugin-ozone — not in agents-common.

Customer enablement

Upgrade 2.8.0 → 2.9.0

Ranger 2.8.0 does not have this feature flag. On upgrade to 2.9.0, patch J10065 runs once during DB upgrade. Behavior depends on ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition at first 2.9 Admin startup.

Path A — Flag OFF (default)

1. Upgrade 2.8 → 2.9 (leave flag unset / false).
2. J10065 writes enableActionMatcherInPoliciesCondition=false to def_options and removes action-matches from the stored ozone service-def.
3. Restart Admin and Ozone OM.

Path B — Flag ON at upgrade

1. Before first 2.9 Admin start, set property to true in ranger-admin-site.xml.
2. Upgrade and run DB scripts — J10065 keeps action-matches and persists option true.
3. Restart Admin and Ozone OM.

Enable later (upgraded 2.9 with flag OFF → turn feature ON)

With commit 4107076af:

1. Set in ranger-admin-site.xml:

   <property>
     <name>ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition</name>
     <value>true</value>
   </property>

2. Restart Ranger Admin, then Ozone OM.
3. Verify ozone service-def API shows enableActionMatcherInPoliciesCondition: true and action-matches in policyConditions.

No manual def_options update is required for Admin UI / API / plugin service-def download. DB def_options may still show false until something persists an update — runtime serving uses admin config.

Upgrade 2.9 → 3.0 (same J10065 patch id)

If 2.9 ran J10065 with flag OFF:

• x_db_version_h marks J10065 applied
• DB has enableActionMatcherInPoliciesCondition=false
• action-matches removed from stored service-def

On 3.0 upgrade with flag ON in ranger-admin-site.xml:

• J10065 is skipped (already applied)
• With runtime fix (#1073 / this PR), admin config wins after restart — same as the 2.9 late-enable path above

Quick reference

Scenario	What to do
2.8 → 2.9, no action policies needed	Path A — default flag OFF
2.8 → 2.9, need action policies immediately	Path B — flag true before first 2.9 Admin start
Already on 2.9 flag OFF, enable later	Set site XML true + restart Admin (runtime fix)
2.9 → 3.0, J10065 already ran OFF	Set site XML true on 3.0 + restart Admin (runtime fix on both branches)
J10065 ran OFF, need DB row re-insert only	Do not re-run J10065 (error 2007); optional ops SQL if policies reference deleted condition def

Test plan

Unit tests

• mvn test -pl security-admin -am -Dtest=TestRangerServiceDefService -Dsurefire.failIfNoSpecifiedTests=false
• testOzoneActionPolicyConfigTrueOverridesStoredFalseOption — config=true, DB option=false → served true
• testOzoneActionPolicyConfigTrueRestoresMissingActionMatchesCondition — config=true, condition stripped → restored
• mvn test -pl plugin-ozone -Dtest=TestRangerOzoneAuthorizer
• mvn verify -pl agents-common,plugin-ozone (Checkstyle, PMD, SpotBugs, RAT)

Manual — flag OFF / ON

• Ozone service-def API reflects flag; authorization works; legacy policies do not hang UI
• Flag ON: Action condition in UI; policy save/download; plugin eval

J10065 patch

• Flag OFF → action-matches removed when no policies reference it
• Flag OFF with referencing policies → patch blocked
• Flag ON at fresh install → action-matches present

[fmorg-git]

hi @ramackri - thanks for this. Per discussion internally, it seems a lot of knobs for the user to configure. Please give me a couple hours to see if I can improve this. Thanks. (Also, thanks for the fix I identified for accessType)

[fmorg-git]

hi all - it appears it is possible to do this with one flag - please see this PR #1073. Can you please check it out to see if it looks good? It looks good from my local testing.