[BugFix] Fix GRANT on ALL VIEWS/MVs failing for external catalogs

[VijayShekhawat7]

Why I'm doing:

GRANT ALL ON ALL VIEWS IN DATABASE fails with cannot find db: <db_name> when
the current session is connected to an external catalog (e.g., Iceberg via REST).
The equivalent GRANT ALL ON ALL TABLES IN DATABASE works correctly.

This happens because ViewPEntryObject and MaterializedViewPEntryObject resolve
databases exclusively through the local (internal) metastore, while
TablePEntryObject already has catalog-aware resolution that supports external
catalogs.

What I'm doing:

Mirror the catalog-aware resolution pattern from TablePEntryObject into
ViewPEntryObject and MaterializedViewPEntryObject:

• AuthorizationAnalyzer.analyzeTokens: Prepend session.getCurrentCatalog()
  for VIEW and MATERIALIZED_VIEW object types (matching existing TABLE
  behavior) in both the ALL and non-ALL grant paths.
• ViewPEntryObject.generate: Accept 3-element token lists [catalog, db, view],
  resolve catalog ID via CatalogMgr, use DbPEntryObject.getDatabaseUUID() for
  external catalogs (returns DB name directly without local metastore lookup), and
  return view names directly as UUIDs for external catalogs.
• MaterializedViewPEntryObject.generate: Same fix as ViewPEntryObject.

Fixes #71211

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

Fixes GRANT/REVOKE on ALL VIEWS / ALL MATERIALIZED VIEWS when the session is using an external catalog by making view/MV privilege object resolution catalog-aware (mirroring existing table behavior).

Changes:

• Update AuthorizationAnalyzer.analyzeTokens to prepend session.getCurrentCatalog() for VIEW/MATERIALIZED_VIEW (and to consistently emit [catalog, db, object] tokens for non-ALL paths).
• Extend ViewPEntryObject and MaterializedViewPEntryObject to accept 3-part tokens and resolve external catalogs via CatalogMgr, using external names as privilege “UUIDs” similarly to external tables.
• Add analyzer tests covering GRANT/REVOKE of ALL views/MVs in external catalogs (plus a negative case for a non-existent catalog).

Reviewed changes

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

Show a summary per file

File	Description
fe/fe-core/src/test/java/com/starrocks/sql/analyzer/PrivilegeStmtAnalyzerV2Test.java	Adds parsing/analyzer regression tests for GRANT/REVOKE on ALL views/MVs in an external (mocked hive) catalog.
fe/fe-core/src/main/java/com/starrocks/sql/analyzer/AuthorizationAnalyzer.java	Ensures VIEW/MV token analysis is catalog-aware and aligns token shapes with TABLE behavior.
fe/fe-core/src/main/java/com/starrocks/authorization/ViewPEntryObject.java	Implements 3-token [catalog, db, view] generation and external-catalog resolution/ID strategy for views.
fe/fe-core/src/main/java/com/starrocks/authorization/MaterializedViewPEntryObject.java	Implements 3-token [catalog, db, mv] generation and external-catalog resolution/ID strategy for materialized views.
fe/fe-core/src/main/java/com/starrocks/authorization/AuthorizationMgr.java	Updates built-in “ALL objects” initialization for VIEW/MV to use 3-token wildcards consistent with catalog-aware generation.

[HangyuanLiu]

Thanks for working on this. I don't think this is ready yet.

The main issue is that this patch only fixes the GRANT/REVOKE statement analysis and PEntryObject generation path for external-catalog VIEW / MATERIALIZED_VIEW privileges, but it does not appear to wire the runtime authorization path through consistently.

Specifically:

• AuthorizationAnalyzer now produces catalog-aware tokens for VIEW / MATERIALIZED_VIEW in the grant path, and ViewPEntryObject / MaterializedViewPEntryObject now accept external-catalog objects.
• However, the authorization check path still does not appear to consume those privileges consistently. In Authorizer.doCheckTableLikeObject, external view types such as HIVE_VIEW / ICEBERG_VIEW / PAIMON_VIEW still go through the TABLE privilege branch instead of the VIEW privilege branch.
• On the native auth side, NativeAccessController.checkViewAction / checkAnyActionOnView and the MV equivalents still build objects from [db, object] without catalog information, so they still default back to the internal catalog semantics.
• Authorizer.checkAnyActionOnOrInDb also only applies the VIEW / MV “extra checkers” for the internal catalog path.

So with the current patch, GRANT ... ON VIEW/MATERIALIZED_VIEW against an external catalog may succeed syntactically and may even persist a privilege entry, but I do not see evidence that the granted privilege will actually be matched by the real authorization flow when the system checks access later.

The second issue is test coverage:

• The new tests only assert parser/analyzer success or failure via parseStmtWithNewParser(...).
• They do not verify the generated privilege object shape, and more importantly they do not verify that a user who receives the external VIEW / MV privilege can actually pass a later authorization check.

Please add a real end-to-end authorization test for the actual privilege enforcement path, not just parser coverage. I strongly recommend deploying this against a real external catalog and verifying the full workflow in a running system as well: grant the privilege, then validate the downstream access checks that are supposed to consume it. Right now this looks very likely to fix statement acceptance without fully fixing correctness.

[rad-pat]

@VijayShekhawat7 are you able to update this PR - we would love a fix for the issue

[VijayShekhawat7]

Thanks for the thorough review @HangyuanLiu, You're right that the original patch only fixed the grant/revoke statement path without wiring the runtime authorization checks. I've pushed a follow-up commit that addresses all the issues you raised:

1. External view types now route through VIEW privilege branch
Moved HIVE_VIEW, ICEBERG_VIEW, PAIMON_VIEW from the TABLE case to the VIEW case in Authorizer.doCheckTableLikeObject, so external views are checked against VIEW privileges rather than TABLE privileges.

2. NativeAccessController view/MV methods are now catalog-aware
checkViewAction, checkAnyActionOnView, checkMaterializedViewAction, and checkAnyActionOnMaterializedView now resolve catalog from TableName (defaulting to internal when null) and pass 3-token [catalog, db, object] lists — matching the existing checkTableAction / checkAnyActionOnTable pattern.

3. checkAnyActionOnOrInDb now applies VIEW/MV checkers for external catalogs
Added catalog-aware overloads checkAnyActionOnAnyView(context, catalog, db) and checkAnyActionOnAnyMaterializedView(context, catalog, db) to the AccessController interface and NativeAccessController. The checkAnyActionOnOrInDb method now includes VIEW/MV privilege checkers for external catalogs (previously only TABLE was checked).

4. End-to-end authorization tests
Added testGrantViewExternalCatalog and testGrantMaterializedViewExternalCatalog in AuthorizationMgrTest that:

• Create an external Iceberg catalog
• Verify Authorizer.checkViewAction / checkMaterializedViewAction throws AccessDeniedException before grant
• Grant SELECT on ALL VIEWS/MVs in a database
• Verify Authorizer.checkViewAction, checkAnyActionOnView, and checkAnyActionOnOrInDb all pass
• Revoke the grant
• Verify the check fails again

Also fixed a pre-existing inconsistency in doCheckTableLikeObject where the TABLE branch's else path used checkTableAction(context, dbName, tbl.getName(), privilegeType) (defaulting to internal catalog) while the null path correctly used tbl.getCatalogName().

[rad-pat]

@HangyuanLiu , possible to review please?

[HangyuanLiu]

@jaogoy please add you review

[github-actions]

[Java-Extensions Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[FE Incremental Coverage Report]

✅ pass : 116 / 136 (85.29%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	com/starrocks/authorization/AccessController.java	0	2	00.00%	[97, 117]
🔵	com/starrocks/authorization/MaterializedViewPEntryObject.java	32	39	82.05%	[49, 53, 63, 92, 93, 94, 97]
🔵	com/starrocks/sql/analyzer/Authorizer.java	20	23	86.96%	[237, 238, 321]
🔵	com/starrocks/authorization/ViewPEntryObject.java	34	39	87.18%	[50, 54, 93, 94, 95]
🔵	com/starrocks/authorization/NativeAccessController.java	15	17	88.24%	[168, 169]
🔵	com/starrocks/sql/analyzer/AuthorizationAnalyzer.java	10	11	90.91%	[361]
🔵	com/starrocks/authorization/AuthorizationMgr.java	5	5	100.00%	[]

[github-actions]

[BE Incremental Coverage Report]

✅ pass : 0 / 0 (0%)