Description
Moving Trino authorizer implementation from Ranger git repo to Trino repo has several advantages, including:
- Keeping the authorizer in sync with the updates in SystemAccessControl interface. For example, following changes in the latest Trino repo are not compatible with the Trino authorizer in Ranger repo:
- SystemAccessControl.checkCanAccessCatalog(): removed
- SystemAccessControl.getRowFilter(): replaced with getRowFilters()
- SystemAccessControl.getColumnMasks(): replaced with getColumnMask()
- SystemAccessControl.checkCanSetSystemSessionProperty(): removed
- SystemAccessControl.checkCanImpersonateUser(): signature changed
- SystemAccessControl.checkCanAccessCatalog(): removed
- SystemAccessControl.checkCanCreateSchema(): signature changed
- SystemAccessControl.checkCanExecuteQuery(): removed
- SystemAccessControl.checkCanViewQueryOwnedBy(): removed
- SystemAccessControl.filterViewQueryOwnedBy(): signature changed
- SystemAccessControl.checkCanKillQueryOwnedBy(): removed
- SystemAccessControl.checkCanGrantExecuteFunctionPrivilege(): removed/replaced
- SystemAccessControl.checkCanExecuteFunction(): signature changed
- ViewExpression(): constructor changed
- AccessDeniedException.denyGrantExecuteFunctionPrivilege(): removed
- Trino requires more recent JDK versions (currently JDK 22) than Ranger repo (which still supports JDK 8). Trino authorizer is built separately, as a second phase, in Ranger repo using higher JDK versions. Moving the authorizer to Trino repo will avoid this additional step.
Trino seems to have a class loader isolation in place for its plugins, which can eliminate the need for the shim layer used in Ranger plugin. This needs to be considered along with this move.
Though the authorizer implementation would move to Trino repp, Ranger repo will continue to have modules used in Ranger admin server for resource look up and default policy creation (class RangerServiceTrino).