<@U0A71G31CDV> I'm using 4.0.6 starrocks with rang...
# questions-and-troubleshooting
m
@Rocky I'm using 4.0.6 starrocks with ranger for authorization using starrocks-ranger plugin. I could see below case is getting bypassed from ranger. I masked the phone field in ranger. table - test.user , column - phone Mask working for below - showing masked values
Copy code
select phone from test.user limit 2
(select phone from test.user limit 2)
Mask not working(ranger bypass) for below - showing actual phone values
Copy code
with phonebase as (select phone from test.user limit 2)
(select phone from phonebase)
is there any fix from starrocks plugin for this case in any later versions of plugin?
r
The issue you are describing, where Ranger masking policies are bypassed when using Common Table Expressions (CTEs), is a known behavior in earlier versions of the StarRocks 4.0.x branch. Analysis of the Issue In StarRocks version 4.0.x, the introduction of a new query planner changed how CTEs (and logical views) are expanded. In version 4.0.6, the Ranger Access Controller sometimes fails to propagate or re-apply masking expressions during the logical expansion of a CTE. This results in the "masking bypass" you're seeing: the direct query triggers the masking logic, but the reference within the CTE does not. The Fix A specific fix for this type of policy bypass (specifically regarding how Ranger policies are applied during the expansion of views and logical structures) was introduced in StarRocks version 4.0.13 (and backported to 3.5.18). * Fixed in: StarRocks 4.0.13 and later. * Relevant PR/Issue: #73265 ("Ranger row-filter/masking policies are now correctly applied during view/CTE expansion"). In later versions, the planner ensures that when a CTE is "anchored" or expanded, the Ranger plugin is called to check for masking and row-filtering policies on the underlying physical tables before the query is executed. Recommendations 1. Upgrade to 4.0.13 or later: Upgrading to the latest patch in the 4.0.x series (e.g., 4.0.13+) should resolve the CTE bypass. 2. Verify Plugin Version: Ensure you are using the latest version of the
starrocks-ranger-plugin
JAR that corresponds to your upgraded FE version, as some logic resides in the plugin's interaction with the FE's Access Controller. 3. Workaround (Temporary): If you cannot upgrade immediately, you may find that using nested subqueries instead of CTEs sometimes forces the masking logic to trigger more reliably in older versions, though this is not guaranteed for all complex plans:
Copy code
sql
    -- Potentially works in older versions where WITH fails
    SELECT phone FROM (SELECT phone FROM test.user LIMIT 2) t;
For further tracking or if the issue persists after upgrading, it is recommended to check the official StarRocks GitHub issues for any ongoing Nereids planner regressions related to Ranger. References • administration/user_privs/authorization/ranger_plugin.md