Also ranger service definition dont have SELECT option for View policy.

Hello! I'm Rocky, your StarRocks chatbot. Regarding your question about Apache Ranger and views in StarRocks: Should Ranger users be able to query all views? No. By design, when

access_control = ranger

is configured, StarRocks should delegate all authorization checks to Apache Ranger. This includes views. Users should only be able to query (perform

SELECT

on) views for which they have an explicit "Allow" policy in Ranger. Starting from StarRocks v2.2, the privilege model was simplified so that users only need the SELECT privilege on the View itself, and do not necessarily need permissions on the underlying base tables (unless the view is configured otherwise). Regarding the reported issue and

ColumnPrivilege.java

If users are able to query all views without specific policies, this suggests a potential gap in the authorization logic for views within the Ranger plugin integration. In StarRocks, views are treated as objects with their own schema. When a query is executed against a view, StarRocks performs: 1. An object-level check (Is the user allowed to

SELECT

from this view?). 2. A column-level check (Is the user allowed to access these specific columns?). The file you mentioned,

ColumnPrivilege.java

, is central to how StarRocks handles fine-grained column-level access. If the logic in this class (or the classes it interacts with for Ranger) does not correctly identify a

VIEW

as a resource that needs a Ranger authorization call, or if it defaults to

ALLOWED

when an object is a view, then users would indeed be able to query any view. Recommendations: 1. Check Ranger Service Definition: Ensure that your

ranger-servicedef-starrocks.json

is up to date. Views are typically mapped to the

table

resource type in Ranger. If StarRocks is sending a request for a view but Ranger doesn't recognize it as a valid resource type or if the mapping is broken, it could cause issues. 2. Review Policies: Verify that there isn't a broad "Allow all" policy (e.g.,

*

for database/table) in Ranger that might be granting access unintentionally. 3. Potential Bug: Since you've identified a specific code path in

branch-3.5

, this may be a bug where view-specific column privileges are not being correctly routed to the Ranger authorizer. I recommend: * Checking FE Logs: Look for "Ranger" related logs in

fe.log

. If authorization is working correctly, you should see Ranger plugin activity. * Report to Community: If the behavior persists despite correct policies, please report this on the StarRocks GitHub Issues page. Mentioning the specific logic in

ColumnPrivilege.java

will be very helpful for the maintainers to verify the fix. In summary: Ranger users should definitely not have access to all views by default, and your observation about

ColumnPrivilege.java

likely points to a missing check in the 3.5 branch's authorization bridge.